It runs two phases. Filtering removes nodes that cannot host the pod, based on resource requests against allocatable capacity, node selectors, taints the pod does not tolerate, and volume or affinity constraints. Scoring then ranks the survivors using rules like spreading across nodes and preferring less loaded ones. The winner gets bound, and the kubelet on that node actually starts the pod.
Why interviewers ask this
Scheduling shows up in real incidents as pending pods and uneven load, so the interviewer wants to know you can debug it. The key detail they listen for is that scheduling uses requests, not limits or actual usage, which explains most surprised faces during capacity incidents. Affinity, taints and topology spread constraints show you have shaped placement deliberately rather than accepting defaults.
How to structure your answer
- Name the two phases: filter then score, then bind.
- Call out that requests drive placement, not limits or live usage.
- List the levers: selectors, affinity, taints, topology spread.
- Say how you debug a pod stuck in Pending.
Example answer
The scheduler watches for pods with no node assigned and runs them through filtering and scoring. Filtering throws out any node that cannot possibly work: not enough allocatable CPU or memory for the pod's requests, a node selector that does not match, a taint with no matching toleration, a volume that cannot attach in that zone. Scoring then ranks what is left, favoring spreading and balanced utilization, and the top node wins and gets bound. The detail that matters operationally is that it schedules on requests, not on what the pod actually uses. So a cluster can look fifteen percent utilized in the dashboards and still refuse to schedule anything, because everyone set requests far above real usage. When a pod sits Pending, I go straight to the events on the pod, since the scheduler tells you exactly which predicate failed and on how many nodes. For shaping placement I use topology spread constraints across zones for availability, and taints with tolerations to keep general workloads off nodes with special hardware.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What is the difference between a pod being evicted and being preempted?
- How do requests and limits interact with quality of service classes?
- How would you keep two replicas of the same service off one node?
Related devops engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions