Ask a candidate to define a deadlock and most of them nail it in under ten seconds: mutual exclusion, hold and wait, no preemption, circular wait. Ask the same candidate to detect one in a system that's already stuck, and the room goes quiet. We've watched this exact gap show up over and over in operating system questions logged through LastRoundAI's live interview copilot: interviewers rarely stop at the definition. They follow up.
That follow-up is what separates a candidate who memorized flashcards from one who understands how a scheduler, a lock, or a page table actually behaves under load. This post covers the operating system interview questions that come up most in SDE-1 and SDE-2 loops, the kind of loops a solid resume gets you into in the first place, organized by the six areas interviewers actually probe: processes vs. threads, CPU scheduling, deadlock, synchronization, memory management, and context switching. Real answers, not just definitions, the same kind you can drill anytime with LastRoundAI's free tools.
Why operating system interview questions haven't gone away
Companies keep asking this stuff because production incidents look exactly like OS textbook problems with better names. A service that hangs under load is usually a thread starving on a lock. A container that gets OOM-killed is a paging and working-set problem wearing a Kubernetes costume. Interviewers who've been paged at 2am know the difference between someone who read a summary once and someone who can reason from first principles, and that's what these questions are testing for, whether or not the interviewer says so out loud.
Process vs. thread, and why context switching costs what it costs
What's the difference between a process and a thread?
A process is an independent unit of execution with its own address space, including its own code, data, heap, and stack, plus its own set of open file descriptors and other kernel resources. A thread is a lighter-weight unit of execution that lives inside a process and shares that process's address space and open files with every other thread in it.
The POSIX threads reference is blunt about what's actually shared: threads in the same process see the same global memory (data and heap segments) and the same set of open file descriptors, but each thread keeps its own thread ID, its own stack, its own signal mask, and its own set of registers, per the pthreads(7) man page. That's the whole reason threads exist: creating one is cheaper than creating a process, because the kernel doesn't have to set up a fresh address space, and communicating between two threads doesn't require IPC, because they're already looking at the same memory.
What actually happens during a context switch, and why is it expensive?
A context switch is the CPU saving the full state of the currently running process or thread (program counter, registers, stack pointer) into its control block, then loading the saved state of the next one to run. It happens on every timer interrupt, every blocking I/O call, and every time the scheduler decides something else deserves the CPU more.
The expense isn't really the save-and-restore itself; that part is fast. It's the side effects. Switching between two processes usually means swapping the page table too, which can flush the TLB and cost a wave of slow memory lookups right after the switch, on top of cold caches. Switching between two threads of the same process skips that step entirely, since they share one address space, which is the main reason thread context switches are cited as noticeably cheaper than process context switches. Exactly how much cheaper depends on the kernel and hardware, and interviewers who want an exact multiplier are usually fishing to see if you'll make one up. Don't.
CPU scheduling: same goal, four different trade-offs
Every scheduling algorithm is solving the same problem (which ready process gets the CPU next) with a different opinion about what's fair. Here's how the four classics compare.
| Algorithm | Preemptive? | Main strength | Main failure mode |
|---|---|---|---|
| FCFS (First-Come, First-Served) | No | Simple, no starvation | Convoy effect: one long job blocks every short job behind it |
| SJF (Shortest Job First) | Optional (SRTF if preemptive) | Minimizes average waiting time on paper | Needs burst-time prediction; long jobs can starve |
| Round Robin | Yes, fixed time quantum | Fair, responsive, good for time-sharing | Quantum too small: overhead eats throughput. Too large: degenerates into FCFS |
| Priority Scheduling | Either | Lets urgent work jump the queue | Low-priority jobs can starve without aging |
Which scheduling algorithm minimizes average waiting time, and why doesn't everyone just use it?
Shortest Job First minimizes average waiting time among these four, and it's provably optimal if you actually know each job's burst time in advance. That's the catch. Real schedulers don't know burst time in advance, only an estimate based on past behavior, so pure SJF is closer to a textbook idea than a production algorithm. It's still worth knowing cold, because interviewers use it to check whether you understand why round robin exists at all: round robin trades a bit of that optimal waiting time for something SJF can't offer, a guarantee that no process waits forever.
Deadlock: the four conditions, and the three ways out
What are the four necessary conditions for deadlock?
A deadlock can only happen if all four of the Coffman conditions hold at once: mutual exclusion (a resource can only be held by one process at a time), hold and wait (a process holding one resource is waiting on another), no preemption (a resource can't be forcibly taken away), and circular wait (a cycle of processes, each waiting on a resource held by the next). Break any single one of the four and deadlock becomes impossible, which is the entire logic behind prevention.
What's the difference between deadlock prevention, avoidance, and detection?
These are three different strategies, not synonyms, and mixing them up in an interview is a fast way to lose points. Prevention removes one of the four Coffman conditions structurally, for example by forcing every process to request all its resources up front (killing hold and wait) or by imposing a global ordering on resource requests (killing circular wait). Avoidance is more dynamic: the system checks, before granting any request, whether doing so would leave it in a safe state, which is what the Banker's algorithm does. Detection is the least conservative of the three. It lets deadlocks happen, periodically scans the resource-allocation graph for cycles, and recovers by killing or rolling back a process once a cycle is actually found.
Prevention is the cheapest to reason about and the most restrictive in practice. Detection is the most permissive and the most expensive to recover from. Most production systems don't implement any of the three formally; they just size resource pools generously enough that the question rarely comes up, which is a slightly unsatisfying answer but an honest one.
Process synchronization: where "race condition" stops being an interview term
What's a race condition, in practice?
A race condition happens when two or more threads access shared data concurrently, at least one of them writes, and the final result depends on the order the operations happen to interleave in. The classic example is two threads both running counter++ on the same variable: that single line is actually a read, an increment, and a write, and if both threads read the same starting value before either writes back, one increment silently disappears.
What three properties does a correct critical-section solution need?
Mutual exclusion, so only one process can execute in the critical section at a time. Progress, so a process not in the critical section can't block another process from entering it. And bounded waiting, so there's a limit on how many times other processes can enter the critical section before a waiting process gets its turn. A solution that satisfies mutual exclusion but not bounded waiting still isn't correct, even though it "works" most of the time, and that distinction is exactly what separates a strong answer from a memorized one.
Mutex vs semaphore: what's actually different?
A mutex is a locking mechanism with ownership: whichever thread locks it is the only thread allowed to unlock it, and it's strictly binary, locked or unlocked. A semaphore is a signaling mechanism built around an integer counter that can go above 1, has no concept of ownership, and can be incremented (signaled) by a thread that never decremented it in the first place. A binary semaphore looks like a mutex from a distance, but the ownership rule is what makes them behave differently in practice, particularly for producer-consumer patterns where the thread that signals "resource available" often isn't the thread that consumed it.
Here's the classic wait/signal pattern protecting a shared counter, which is about as much pseudo-code as this topic needs:
wait(mutex); // enter critical section
counter++; // only one thread here at a time
signal(mutex); // exit critical sectionMemory management: paging, segmentation, and the thrashing question nobody explains well
Paging vs segmentation, in one answer
Paging splits both physical and logical memory into fixed-size blocks (frames and pages), which avoids external fragmentation but wastes a bit of memory to internal fragmentation on the last partial page of anything. Segmentation splits memory into variable-size chunks that map to logical units a programmer actually thinks in, like code, stack, and heap, which fits how programs are structured but reopens the door to external fragmentation as segments of different sizes get allocated and freed.
Is a page fault always a bad thing?
No, and this is where a lot of candidates lose points by treating "page fault" as synonymous with "bug." A page fault just means the process referenced a page that isn't currently mapped into physical memory, and demand paging depends on this happening: pages get loaded only when something actually touches them, which is exactly what keeps memory usage lower than loading an entire program up front. The Linux kernel's own memory documentation describes this directly: virtual memory "allows to keep only needed information in the physical memory," which is demand paging by definition, per the kernel.org memory management concepts guide. A page fault only becomes a real problem when they start happening constantly on pages that were just evicted, because that's the first sign of thrashing.
What is thrashing, and how do you actually fix it?
Thrashing is when a system spends more time swapping pages in and out than running actual instructions, usually because too many processes are competing for too little physical memory and each one's working set (the pages it needs in the near term) can't stay resident at the same time. CPU utilization drops even though the system looks maximally busy, which is the counterintuitive part interviewers like to poke at. The fix is almost never "add more processes to spread the load," which makes it worse. It's reducing the degree of multiprogramming, or sizing memory allocation around each process's actual working set instead of an arbitrary fixed share.
The pattern underneath all of these
Every one of these topics has the same shape: a clean definition that's easy to memorize, followed by a "now what" that only shows up if you've actually reasoned through the mechanism. We don't have a clean percentage to put on this, and any blog that hands you one exact number here is probably guessing, but the direction is consistent enough in the copilot logs we've reviewed that we're comfortable saying it out loud: candidates who can explain a Coffman condition rarely stumble on the definition part. They stumble on "okay, so how would you actually detect that in a running system," which is a different skill than recall.
That's the part worth rehearsing out loud, not just reading. LastRoundAI's AI interview copilot listens to the live question and surfaces the follow-up angle in real time, so when an interviewer pushes past "what's a deadlock" into "how would you avoid one here," you're not starting from zero. If you're prepping for a specific company loop rather than operating system interview questions in the abstract, the kind of loop LastRoundAI's auto-apply tool helps you land in the first place, our breakdowns of Microsoft SDE interview questions and Amazon SDE-2 interview questions cover the systems and OS questions candidates actually reported, not a generic list.
Memorize the four conditions if you want. Just don't stop there, because neither will the interviewer.
How this list was built
Worth being straight about where these questions come from, because plenty of pages in this category are not. The set was compiled from a research pass across official documentation, vendor release notes, published engineering writing and public discussion of hiring processes, then cross-checked against the current version of each technology so nothing here describes behaviour that has since changed.
What that means in practice: these are the questions the material supports as reasonable and current for this role, not a transcript of any one company's loop. We have not sat in on your interview and we are not going to claim we have. Treat the list as well-sourced preparation rather than a leaked question bank, and expect your panel to phrase things their own way.
If you spot something out of date, tell us at contact@lastroundai.com and we will fix it.
Frequently asked questions
How long does it take to prepare for a operating systems interview?
If you already work with operating systems day to day, a focused week on the areas you avoid in practice is usually enough. Coming in cold, expect three to four weeks. The gap is rarely knowledge; it is being able to explain something you normally just use.
What operating systems topics come up most often?
Interviewers concentrate on the parts that cause production incidents rather than the parts that are pleasant to learn. Expect the fundamentals to be assumed and the follow-up questions to sit one layer below what a tutorial covers.
Do I need hands-on operating systems experience to pass?
It shows quickly either way. Textbook answers hold up until the interviewer asks what you did when it broke, and that is usually the question that separates candidates. A small real project you can discuss honestly beats a longer list of familiarity claims.
Is operating systems still worth learning in 2026?
For interview purposes the question is really whether the teams you are targeting use it, which is worth checking against their actual job postings rather than general popularity rankings. Where it is in use it tends to be deeply embedded and slow to replace.