CPU Scheduling for Interviews: the only guide you need

On a single CPU core, only one process runs at a time. When multiple processes are ready, the operating system's scheduler picks which one gets the CPU next. The goal depends on the system: minimise average waiting time, maximise throughput, guarantee responsiveness, or be fair. No single algorithm wins on every metric — which is exactly why interviewers ask about the trade-offs.

Three numbers matter for almost every question:

• Completion Time (CT): when a process finishes.
• Turnaround Time (TAT) = CT − Arrival Time. Total time in the system.
• Waiting Time (WT) = TAT − Burst Time. Time spent waiting, not running.

Average waiting time and average turnaround time are just the means across all processes. Response time — first time a process gets the CPU minus its arrival — matters for interactive systems.

The ready queue is a plain FIFO. Whoever arrives first runs first, to completion. It's non-preemptive and trivially fair in arrival order — but it suffers the convoy effect: one long process at the front makes everyone behind it wait, ballooning average waiting time.

Interview trap: put a burst-20 process first and three burst-2 processes behind it. FCFS gives a terrible average; SJF on the same set is dramatically better. Being able to say why instantly signals you understand the convoy effect.

Among the processes that have arrived, run the one with the smallest burst time next. SJF is provably optimal for minimising average waiting time when all jobs are available — but it needs to know burst times in advance (in practice, estimated), and it can starve long jobs if short ones keep arriving.

The preemptive version: whenever a new process arrives, compare its burst to the remaining time of the running process and switch if it's shorter. SRTF gives the lowest average waiting time of the classic algorithms, at the cost of more context switches and worse starvation for long jobs.

Interview trap: SRTF questions punish arithmetic slips because you re-evaluate at every arrival. Build the Gantt chart one time-unit at a time and you won't miss a preemption.

Each process gets a fixed time quantum; if it doesn't finish, it goes to the back of the ready queue. Round Robin is preemptive, fair, and great for responsiveness — the backbone of interactive scheduling.

The quantum is everything. Too large and RR degrades to FCFS. Too small and context-switch overhead dominates. A common rule of thumb: the quantum should be slightly larger than the time for a typical interaction, so ~80% of bursts finish within one quantum.

Interview trap: the exact queue order after a preemption. When a process's quantum expires at the same instant another arrives, conventions differ on who enters the queue first — state your assumption explicitly and stay consistent.

Each process has a priority; the highest-priority ready process runs (lower number usually = higher priority). It can be preemptive or not. The classic problem is starvation: a low-priority process may never run. The fix is aging — gradually raise the priority of waiting processes so they eventually run.

You will forget this in a week if you only read it. You won't forget it if you operate it: change a quantum and watch the average waiting time move, drop in a long job and watch FCFS convoy or SJF starve. That muscle memory is what gets you through the interview when you're nervous.

SimDojo's CPU scheduling simulator is free — no signup. Edit the process table, switch algorithms, and an AI tutor reads your exact Gantt chart and explains every result. Hit "new AI scenario" for infinite fresh practice.