Operating System Interview Questions for Freshers (2026) — with Answers
Updated August 2026
Operating systems is the core subject freshers most often postpone and most reliably get asked about. It has no visible payoff in your project, so it feels skippable — right up to the moment an interviewer asks why your program has threads and what happens when two of them touch the same variable.
The good news is that the asked portion is small and stable. Processes and threads, CPU scheduling, deadlock, synchronisation, and memory management with paging cover the overwhelming majority of fresher OS questions at both service and product companies. Everything else is depth you can add later.
Answer each of these in 30–60 seconds and finish with the reason the mechanism exists — panels reward "why it is there" over the definition. Note that deadlock also appears in our DBMS question set from the database-transaction side; this page handles the operating-system side, and knowing both is what makes the answer land.
Frequently asked questions
What is the difference between a program, a process and a thread?
A program is passive — code sitting on disk. A process is a program in execution, with its own address space, code, data, heap, stack and OS-allocated resources. A thread is a unit of execution inside a process: threads of one process share the code, data and heap but each keeps its own stack, registers and program counter. The one-line consequence interviewers want: creating a process is expensive and isolated, creating a thread is cheap but shares memory — which is exactly why threads need synchronisation and processes mostly do not.
What are the process states?
New (being created), Ready (waiting for the CPU), Running (executing), Waiting or Blocked (waiting for I/O or an event), and Terminated. The transition worth stating precisely is Running → Ready, which happens on preemption when the time slice expires, versus Running → Blocked, which happens when the process itself requests I/O. Students routinely merge those two and it is the follow-up question waiting to be asked.
What is a context switch, and why is it expensive?
The kernel saves the current process's state — program counter, registers, memory-management information — into its process control block, then loads the next process's state and resumes it. It is expensive because it is pure overhead: no useful work happens during it, and it damages cache and TLB locality, so the incoming process starts slow. That cost is the reason time slices are not made arbitrarily small in round-robin scheduling.
Explain the main CPU scheduling algorithms.
FCFS runs jobs in arrival order — simple, but one long job delays everyone behind it (the convoy effect). SJF picks the shortest next burst, which is provably optimal for average waiting time but needs burst lengths you cannot know in advance and can starve long jobs. Priority scheduling picks the highest priority and can also starve low-priority jobs — fixed by ageing. Round Robin gives each process a fixed time slice, which is fair and responsive, and is the basis of what interactive systems actually use. Say which metric each optimises: throughput, waiting time, or response time.
Preemptive vs non-preemptive scheduling?
Non-preemptive lets a running process keep the CPU until it blocks or finishes; preemptive lets the OS take the CPU away, typically on a timer interrupt or when a higher-priority process arrives. Preemption is what makes a system responsive and is what every modern general-purpose OS does. The trade-off is that preemption introduces the possibility of a process being interrupted mid-update of shared data — which is precisely where race conditions come from.
What is a race condition, and what is a critical section?
A race condition is when the result depends on the unpredictable order in which threads execute — two threads incrementing the same counter can produce one increment instead of two, because read-modify-write is not atomic. The critical section is the piece of code touching the shared resource. Any correct solution must satisfy three properties: mutual exclusion (one thread inside at a time), progress (a waiting thread eventually gets in) and bounded waiting (no indefinite postponement).
Mutex vs semaphore — what is the real difference?
A mutex is a locking mechanism with ownership: the thread that locks it is the thread that must unlock it, and it allows exactly one thread in. A semaphore is a signalling mechanism with a counter and no ownership: any thread can signal it, and a counting semaphore admits up to N threads. So use a mutex to protect a critical section, and a semaphore to coordinate — to signal that a resource is available or that an event happened. The ownership point is the part that separates a memorised answer from an understood one.
What is a binary semaphore, and how is it different from a mutex?
A binary semaphore takes values 0 and 1, so it looks like a mutex — but it still has no ownership, meaning thread A can wait on it while thread B signals it. That makes it usable for signalling between threads, which a mutex is not. Practically: if you are protecting data, use a mutex; if you are telling another thread something happened, a binary semaphore is the right tool.
What is deadlock, and what are the four conditions for it?
Deadlock is when a set of processes are each holding a resource and waiting for one held by another, so none can proceed. It requires all four Coffman conditions simultaneously: mutual exclusion, hold and wait, no preemption, and circular wait. The reason to memorise all four is that every prevention technique works by breaking exactly one of them — for example, requiring a process to request all resources up front breaks hold and wait, and imposing a global ordering on resource acquisition breaks circular wait.
How do operating systems handle deadlock?
Four broad approaches. Prevention — design so one of the four conditions can never hold. Avoidance — grant a request only if the system stays in a safe state, which is what the Banker's algorithm computes using maximum-need declarations. Detection and recovery — allow deadlock, detect it with a resource-allocation or wait-for graph, then kill or roll back a victim. And the pragmatic one used by most general-purpose systems: ignore it, because deadlocks are rare and the prevention overhead is not worth paying. Databases take the detection-and-recovery route; that side is covered in our DBMS question set.
Explain the producer–consumer problem.
A producer thread adds items to a fixed-size buffer and a consumer removes them; the producer must block when the buffer is full and the consumer must block when it is empty, and neither may corrupt the buffer. The standard solution uses a mutex for mutual exclusion on the buffer plus two counting semaphores, "empty" and "full", to track slots. It is the canonical synchronisation question because it needs both mechanisms at once, and it is the cleanest place to show that you know why a mutex alone is not enough.
What is virtual memory, and why does it exist?
Virtual memory lets each process see a large, contiguous address space of its own while physical memory is smaller, shared and fragmented. The MMU translates virtual addresses to physical ones through page tables, and pages not currently in RAM live on disk. It exists for three reasons worth naming: programs larger than physical memory can run, processes are isolated from each other's memory, and physical memory is used efficiently because only the pages actually touched are loaded.
What is paging, and how does address translation work?
Paging splits the virtual address space into fixed-size pages and physical memory into frames of the same size, removing the need for contiguous allocation. A virtual address is split into a page number and an offset; the page number indexes the page table to get a frame number, which is combined with the offset to form the physical address. The TLB caches recent translations, because otherwise every memory access would need an extra memory access to read the page table — mentioning the TLB is what shows you have understood the mechanism rather than memorised the diagram.
What happens on a page fault?
The page is not in physical memory, so the MMU raises a trap to the OS. The OS validates that the reference is legal, finds a free frame — evicting a page with the replacement algorithm if none is free, writing it back to disk first if it was modified — reads the required page in from disk, updates the page table, and restarts the instruction that faulted. Restarting the instruction is the detail candidates miss, and it is the reason a page fault is transparent to the running program.
Explain page replacement algorithms and Belady's anomaly.
FIFO evicts the oldest page and is simple but can evict a heavily used one. Optimal evicts the page not needed for the longest time — unimplementable, since it needs the future, but used as a benchmark. LRU evicts the least recently used page, approximating Optimal well and being what real systems approximate in hardware. Belady's anomaly is the counter-intuitive result that with FIFO, adding more frames can increase page faults; LRU and Optimal are stack algorithms and do not suffer it. That anomaly is a favourite follow-up precisely because it sounds wrong.
What is thrashing, and how is it fixed?
Thrashing is when a system spends more time paging than executing, because processes do not have enough frames to hold their working sets. Each page fault evicts a page another process immediately needs, so faults cascade and CPU utilisation collapses — and a naive scheduler makes it worse by admitting more processes when it sees idle CPU. Fixes: the working-set model, which gives each process enough frames for its active pages, and page-fault frequency control, which adjusts allocation up or down against a target fault rate. Reducing the degree of multiprogramming is the blunt remedy.
Internal vs external fragmentation, and paging vs segmentation?
Internal fragmentation is unused space inside an allocated block — the tail of the last page of a process. External fragmentation is free memory that exists but is scattered in pieces too small to use, which is what contiguous allocation suffers from. Paging uses fixed-size pages, so it eliminates external fragmentation and accepts a little internal fragmentation. Segmentation divides memory along logical lines — code, data, stack — which matches how programmers think but reintroduces external fragmentation because segments vary in size.
What does fork() return, and what are zombie and orphan processes?
fork() creates a child process and returns 0 in the child and the child's PID in the parent, which is how each half knows which it is; it returns a negative value on failure. A zombie is a child that has terminated but whose exit status the parent has not yet collected with wait(), so its entry lingers in the process table. An orphan is a child whose parent terminated first; it gets re-parented to init, which reaps it. Expect the trick version too: n consecutive fork() calls create 2ⁿ − 1 child processes.
What is the difference between user mode and kernel mode?
Kernel mode allows unrestricted access to hardware and all instructions; user mode restricts it, so application code cannot directly touch devices or other processes' memory. A system call is the controlled doorway between them: the application traps into the kernel, the kernel performs the privileged operation and returns. This separation is why a crashing application does not take down the OS, and the mode switch is also why system calls cost more than ordinary function calls.
What are the main IPC mechanisms?
Shared memory — the fastest, since processes read and write a common region directly, but it needs explicit synchronisation. Message passing, including pipes, named pipes and message queues, where the kernel copies data between processes: slower but safer and easier to reason about. Sockets, which additionally work across machines. The trade-off to state: shared memory is fast because the kernel steps out of the way, which is exactly why the correctness burden lands on you.
Don't just read Operating systems questions — get asked them
Phiny's AI interviews you on exactly these topics, follows up on weak answers, and tells you what a stronger answer looks like. Text interviews are free and unlimited.
Start a free AI mock interviewHow to prepare
- OS answers land better with a concrete example than with a definition. "Two threads incrementing a counter without a lock can lose an update" beats reciting the definition of a race condition every time.
- Draw while you speak. A four-state process diagram, a resource-allocation graph with a cycle in it, or a page-table translation sketch turns a shaky verbal answer into a confident one — the rough sheet is there to be used.
- Connect OS to your own project. If you used threads, async I/O, a queue or a database connection pool, you have a genuine story about concurrency — and interviewers much prefer that to textbook recall.
- Prepare the follow-up chains rather than isolated answers: threads → shared memory → race condition → mutex vs semaphore → deadlock → the four conditions. Panels walk down that chain, and students who prepared each answer separately fall off it halfway.
- Pair this with our DBMS set. Deadlock, concurrency and isolation appear on both sides, and a candidate who can move between the OS view and the database view of the same problem sounds noticeably stronger than one who memorised one page.
Where these questions get asked
- TCS NQT guide and Infosys hiring guide — the two biggest exams these questions appear in.
- All company placement guides — pattern, syllabus and rounds for every mass recruiter.