OS interview questions — why "explain a process vs a thread" still gets asked in 2026
Operating systems theory looks like the most irrelevant part of a coding interview. It isn't — it's a proxy for whether you understand what your code is actually doing underneath the framework.
"Why is a company hiring me to write React or Spring Boot asking about process scheduling?" is a fair question, and most candidates never get a real answer to it — just more questions to memorise. The honest answer is that OS questions aren't really about operating systems. They're a proxy for a narrower, more practical thing: do you understand what's happening underneath the abstraction you write code against every day.
Process vs thread — the question that never stops being asked
What gets recited: a process has its own memory space, a thread shares memory with other threads in the same process.
What the interviewer is actually listening for: do you know why that distinction has consequences for the code you write. Two threads sharing memory means a race condition is possible the moment they touch the same variable without coordination — that's why locks, mutexes and thread-safe data structures exist. Two processes don't share memory, so they need something heavier — sockets, pipes, shared memory segments — to talk to each other at all, which is why spinning up a new process is expensive and spinning up a new thread is comparatively cheap.
A candidate who can connect the definition to "this is why my multi-threaded code needs a lock here" has demonstrated something a memorised definition can't fake.
Deadlock — not the definition, the story
Everyone can recite the four conditions for deadlock (mutual exclusion, hold and wait, no preemption, circular wait). Almost nobody can walk through a concrete example without being handed one.
The stronger answer has a story: "Thread A locks resource 1 and waits for resource 2. Thread B locks resource 2 and waits for resource 1. Neither releases what it's holding, so both wait forever." Then the fix: acquire locks in a consistent global order across the whole codebase, so two threads can never be waiting on each other in a cycle. That's the difference between having read about deadlock and having reasoned about it.
Virtual memory — the "why do we even need this" question
The setup candidates get is usually "explain virtual memory," and most launch into "each process gets its own address space" without ever explaining why that's useful. The why is worth having ready: it lets a process behave as if it has a large, contiguous chunk of memory regardless of how fragmented physical RAM actually is, it isolates processes from accidentally (or maliciously) reading each other's memory, and it lets the OS run more processes than would physically fit in RAM by paging inactive memory out to disk. One mechanism, three separate practical payoffs — naming even one unprompted is a stronger answer than the textbook definition alone.
Scheduling — the question that reveals whether you've thought about trade-offs
"How does the OS decide which process runs next" invites a list of algorithm names (round robin, priority scheduling, shortest job first). The stronger answer picks one and explains its trade-off: round robin is fair — every process gets a time slice — but a short, quick task can end up waiting behind several full slices from longer processes, hurting responsiveness. Naming a trade-off, not just a name, is what separates a studied answer from an understood one.
Why this keeps showing up in interviews that aren't "systems" roles
None of this is asked because a web developer will implement a scheduler. It's asked because the same reasoning skill — "what is actually happening underneath this abstraction, and what does that imply" — is the same skill needed to debug a race condition in production code, understand why a service is slow under load, or reason about why two API calls occasionally return inconsistent data. OS questions are a cheap, well-understood proxy for that reasoning, which is why they've survived in interviews for roles that never touch a scheduler directly.
If you want to practice explaining OS fundamentals out loud, with a real follow-up when your answer is thin, try role-specific mock interviews — free to start.