Scheduling Four Apps at Once on Kubernetes and a Node-Feedback Scheduler Plugin

You are in a technical-depth interview for a senior backend infrastructure role on a team that runs its workloads on Kubernetes. After some discussion of Kubernetes scheduling and your day-to-day work, the interviewer poses an open scenario: four applications all request to be scheduled onto the cluster at the same time. You are not given a specification. Instead, you are asked to ask the right questions. Expect the interviewer to volunteer nothing and to stay noncommittal when you propose constraints. The exercise is to drive it yourself: decide which unknowns actually matter, explain what each answer would change, and still arrive at a defensible plan. Later in the same interview, the conversation turns to a scheduling problem the team is facing, and one approach that comes up is having nodes feed information back to the scheduler through a scheduler plugin. Part 2 asks you to design that. ### Clarifying Questions - Is the goal only to surface the right questions, or should you also end with a concrete placement and rollout plan once you have fixed your assumptions? - May you change cluster-level configuration (scheduler profiles, priority classes, quotas, node pools), or only the four applications' own manifests? - Is the cluster's size fixed for this exercise, or can capacity be added? ### Part 1 — Ask the right questions, then commit to a plan Four applications request scheduling at the same time on one Kubernetes cluster. List the questions you would ask, grouped by the scheduling decision each one drives, and explain how different answers would change what you do. Then pick explicit assumptions for anything left unanswered and describe how you would get all four applications placed and running. ```hint Make every question pay for itself For each question, name the scheduling decision that changes with the answer. A question whose answer changes nothing is noise. ``` ```hint Take "at the same time" literally Think about how the scheduler actually consumes four simultaneous requests, and what goes wrong if not everything fits. ``` #### What This Part Should Cover - Questions organized by the decision they drive, not as an unordered checklist - How the scheduler handles simultaneous requests, and what happens when capacity runs short - The mapping from each answer to a concrete Kubernetes mechanism or policy - A committed plan under stated assumptions rather than an open-ended list ### Part 2 — Feed node-side signals back into scheduling The team's exact problem is not specified here. Assume it is this: the scheduler places pods using the resource requests the pods declare, but what nodes actually experience (real CPU and memory use, contention, pressure) can differ a lot from those declarations, so some placements turn out badly. Design a mechanism in which nodes report signals back to the scheduler and a scheduler plugin uses them. Cover which signals are reported, how they reach the scheduler, where the plugin hooks into scheduling, and how you make it safe to roll out. ```hint Keep the hot path local Think about what the scheduler can afford to do for every candidate node of every pod, and where the node data should already be by then. ``` ```hint Metrics lag behind decisions Consider what happens when many pods are scheduled in a burst and every one of them sees the same lightly loaded node. ``` #### What This Part Should Cover - The choice of signals and how they are collected and published - Where in the scheduling cycle the plugin acts, and whether it filters, scores, or both - Staleness, burst behavior, and fallback when node data is missing - A safe rollout and a way to measure whether placements improved ### What a Strong Answer Covers - Drives an ambiguous prompt without guidance: prioritizes the questions that matter most and states assumptions out loud - Accurate knowledge of how the Kubernetes scheduler works (per-pod queue, requests versus limits, filtering and scoring, preemption) - Connects Part 1's placement choices with Part 2's observation that declared requests and real usage diverge - Failure modes: deadlock among partially placed groups, preemption side effects, stale or missing node data - Operational judgment expected at a senior infrastructure level: rollout, observability, and rollback ### Follow-up Questions - Two of the four applications are batch jobs whose workers are useless unless all of them start. What goes wrong with the default scheduler, and what would you add? - After your plugin ships, pods that were placed well at admission drift into hot spots as load changes. Does the scheduler fix that, and if not, what does? - The node-reporting agent crashes on a fifth of the nodes. How should the plugin behave, and how would you notice? - How would you show, before a cluster-wide rollout, that the plugin improves placements rather than just moving problems elsewhere?