Ask a fresher "what is a process" and the definition is usually easy. The useful follow-up is: "if context switches are cheap, why does adding more processes eventually make the machine slower?" That question tests whether the candidate can connect switching, cache effects and paging instead of reciting isolated definitions.
The fifty below run in the five chains an interviewer actually walks: process versus thread, scheduling trade-offs, synchronization to deadlock, paging to thrashing, and a quick-fire layer. Eleven carry a whiteboard-depth answer with the follow-up probe named alongside it; the rest carry the two or three sentences you would give across the table.
Operating system interview questions: how the follow-up chain works
An OS round can start with a definition, then probe whether you understand its consequences. A useful chain runs from process vs thread to context-switch cost, then to what happens when the system spends more time switching or paging than doing useful work. Reaching thrashing cleanly demonstrates that the concepts connect.
Our Operating System bank runs to close to two thousand questions, and its densest pools sit on exactly these core concepts. Question density tells you where the practice material is, not what employers ask most; practise each pool in the Operating System learn module.
Topic pool | Questions in our bank | Practice priority |
|---|---|---|
CPU Scheduling | about 290 | High |
Virtual Memory | about 260 | High |
Memory Management | about 220 | High |
Process Synchronization | about 200 | High |
Deadlock | about 165 | High |
Threads and Process Creation | about 125 | Medium |
Process and thread interview questions (Q1 to Q10)
Q1. What is the difference between a process and a thread? A process is a program in execution with its own address space: code, data, heap, and stack, tracked by the OS in a process control block. Threads are execution units inside a process that share the code, data, and heap but keep a private stack, register set, and program counter. Because threads share an address space, creating one and switching between them is cheaper than for processes. Follow-up probe: "cheaper how, exactly?" That is Q2.
Q2. What happens during a context switch, and what does it cost? The kernel saves the running task's CPU state (registers, program counter, stack pointer) into its PCB, picks the next task, and restores that task's state. The direct cost is the save, restore, and scheduler work. The larger indirect cost is that caches and the TLB now hold the wrong task's data, so the new task starts with misses. Follow-up probe: "is a thread switch cheaper than a process switch?" Yes, switching threads of the same process keeps the address space, so the page-table base does not change and the TLB does not need flushing.
Q3. Draw the process state diagram. New, ready, running, waiting (blocked), terminated. Running to ready happens on preemption; running to waiting happens when the process requests I/O or an unavailable resource. The probe here is the difference between ready and waiting: ready means it lacks only the CPU, waiting means it cannot use the CPU even if offered.
The rest of the process and thread chain:
Q4. What does a PCB contain? Process ID and current state, the saved program counter and CPU registers, scheduling information (priority, queue pointers), memory-management information (page-table or base and limit registers), accounting data, and I/O status such as open files and allocated devices.
Q5. User-level vs kernel-level threads, and who schedules each. User-level threads are managed by a library in user space, so creation and switching are fast, but the kernel sees one schedulable entity: a single blocking system call stalls every thread and they cannot spread across cores. Kernel-level threads are scheduled by the OS itself, so they block independently and run in parallel, at a higher switching cost.
Q6. What does fork() return, and how many processes exist after n forks? It returns 0 in the child and the child's PID in the parent, or -1 on failure, which is how the two copies tell themselves apart. In straight-line code with no branching or exit, n successive forks leave 2 to the power n processes.
Q7. Zombie vs orphan processes. A zombie has already terminated but its parent has not called wait(), so its exit status and PCB entry are still held. An orphan is still running while its parent has died, and init (or systemd) adopts it and reaps it later.
Q8. fork() vs exec(). fork() creates a new process that is a copy of the caller; exec() replaces the current process image with a different program while keeping the same PID. A shell running a command does both: fork, then exec in the child.
Q9. Name IPC mechanisms: pipes and named pipes, message queues, shared memory, and sockets. Shared memory is the fastest because data never passes through the kernel, which is exactly why it needs your own synchronization on top; sockets are the only one of the four that also works across machines.
Q10. Mode switch vs context switch. A mode switch changes privilege level between user and kernel inside the same process, which is what a system call or interrupt does. A context switch changes which process or thread the CPU is running and saves and restores its state. Every context switch involves a mode switch; most mode switches do not involve a context switch.
CPU scheduling interview questions (Q11 to Q18)
Q11. Preemptive vs non-preemptive scheduling. Non-preemptive lets a process keep the CPU until it blocks or finishes (FCFS, non-preemptive SJF). Preemptive can take the CPU away on a timer interrupt or a higher-priority arrival (round robin, SRTF, preemptive priority). Follow-up probe: "why does the round robin time quantum matter?" Too small and the CPU spends its time context switching; too large and round robin degrades into FCFS.
Q12. What is the convoy effect, and why is SJF called optimal? In FCFS, one long CPU-bound process makes every short process behind it wait, like cars behind a truck. SJF gives the minimum average waiting time, but it needs the next CPU burst length, which must be predicted (usually by exponential averaging), and pure SJF can starve long jobs. The fix for starvation is aging: gradually raising the priority of waiting processes.
The rest of the scheduling chain:
Q13. Compute turnaround and waiting time for a given FCFS, SJF, SRTF, or RR table. Draw the Gantt chart first, then read off turnaround = completion time minus arrival time and waiting = turnaround minus burst, and average across processes. In round robin, remember a preempted process rejoins the tail of the ready queue.
Q14. Turnaround time vs waiting time vs response time. Turnaround is total time in the system, waiting is the part spent in the ready queue, and response is arrival to first CPU allocation. Round robin is chosen for response time; SJF minimises average waiting time.
Q15. Multilevel queue vs multilevel feedback queue. A multilevel queue fixes each process to one queue for its lifetime. A multilevel feedback queue lets processes move: a CPU-bound process that burns its quantum is demoted, and a process starving in a low queue is promoted by aging.
Q16. Scheduler vs dispatcher. The scheduler decides which process runs next; the dispatcher actually performs the handover, saving and restoring state, switching mode, and jumping to the right instruction in the new process. The time it takes is dispatch latency.
Q17. Long-term, short-term, and medium-term schedulers. The long-term scheduler admits jobs into memory and so controls the degree of multiprogramming; the short-term scheduler picks the next process for the CPU and runs by far the most often; the medium-term scheduler swaps processes out to relieve memory pressure and back in later.
Q18. Starvation vs deadlock. Starvation is one process waiting indefinitely while others keep being preferred, and it can end on its own or with aging. Deadlock is a set of processes each holding what another needs, and nothing short of intervention resolves it. Deadlock always implies starvation; starvation does not imply deadlock.
Synchronization and deadlock interview questions (Q19 to Q31)
Q19. What is a race condition, and what must a critical-section solution guarantee? A race condition is when the result depends on the interleaving of concurrent accesses to shared data. A correct critical-section solution guarantees mutual exclusion, progress, and bounded waiting. Interviewers often probe with a lost-update example: two threads incrementing a shared counter can lose increments because load, add, store is not atomic.
Q20. Mutex vs semaphore. A mutex is a lock with ownership: the thread that locks it must unlock it, and it protects a critical section. A semaphore is a signalling counter with wait and signal operations; a counting semaphore manages n identical resources, and any thread may signal it. Follow-up probe: solve producer-consumer with semaphores (empty, full, and a mutex) and explain why the wait order matters.
Q21. What are the four conditions for deadlock, and how do prevention, avoidance, and detection differ? Deadlock needs mutual exclusion, hold and wait, no preemption, and circular wait to hold simultaneously. Prevention structurally breaks one condition, most practically by imposing a total order on resource acquisition. Avoidance (the Banker's algorithm) grants a request only if the resulting state is safe, meaning a sequence exists in which every process can finish. Detection lets deadlock happen; with single-instance resources, a cycle in the wait-for graph detects it, while more general cases use allocation and request data. Recovery may abort a process or preempt a resource. The natural follow-up is: "every deadlocked state is unsafe, but is every unsafe state deadlocked?" No.
The rest of the synchronization chain:
Q22. Binary vs counting semaphore. A binary semaphore takes only 0 or 1 and can enforce mutual exclusion, but has no ownership, so any thread may signal it. A counting semaphore takes any non-negative value and tracks n identical resources.
Q23. Peterson's solution and what it guarantees. Two processes share a turn variable and a flag array; each raises its flag, hands the turn to the other, and waits. It guarantees mutual exclusion, progress, and bounded waiting for two processes. It assumes memory operations are not reordered, so on real CPUs it needs memory barriers to hold.
Q24. Spinlock vs sleeping lock, and when spinning is acceptable. A spinlock busy-waits and is the right choice when the expected wait is shorter than a context switch and the holder is running on another core. A sleeping lock blocks the thread and suits long or heavily contended critical sections. Spinning on a single core for a lock held by a descheduled thread wastes the entire quantum.
Q25. Priority inversion and priority inheritance. A high-priority task waits on a lock held by a low-priority task, which a medium-priority task keeps preempting, so the high-priority task effectively runs last. Priority inheritance temporarily raises the lock holder to the waiter's priority so it can finish and release. The Mars Pathfinder resets are the textbook case.
Q26. Livelock vs deadlock. In deadlock the processes are blocked and their states stop changing. In livelock they keep changing state in response to each other, politely stepping aside forever, and make no progress while still burning CPU.
Q27. Readers-writers problem and writer starvation. Readers may share the resource; a writer needs it exclusively. The reader-preference solution lets a steady stream of readers keep a writer waiting indefinitely, which is why writer-preference or a fair FIFO queue over the entry section is the usual fix.
Q28. Dining philosophers and how lock ordering fixes it. Five philosophers each need the two forks beside them; if all pick up the left fork at once, every one holds one and waits for one, which is circular wait. Numbering the forks and always taking the lower-numbered one first (or making one philosopher pick up the right fork first) breaks the cycle.
Q29. Reading a resource-allocation graph for deadlock. Request edges run process to resource, assignment edges resource to process. With one instance per resource type, a cycle means deadlock. With multiple instances a cycle is necessary but not sufficient, so you reduce the graph or run the detection algorithm on the allocation and request matrices.
Q30. Safe vs unsafe state in the Banker's algorithm. A state is safe if some ordering exists in which every process can be granted its maximum remaining need, finish, and return its resources. Unsafe does not mean deadlocked; it means the OS can no longer guarantee that deadlock will be avoided.
Q31. How would you avoid deadlock in multithreaded code you write? Impose one global order on lock acquisition and never take locks in a different order, which kills circular wait outright. Beyond that, hold locks for the shortest possible span, prefer a single coarse lock over nested fine ones until profiling says otherwise, and use timed lock attempts so a mistake surfaces as a logged failure rather than a hang.
Memory management and virtual memory interview questions (Q32 to Q43)
Q32. How does paging work? Physical memory is split into fixed-size frames and logical memory into pages of the same size. A page table maps page numbers to frame numbers, so a logical address (page number, offset) becomes (frame number, offset). Paging removes external fragmentation but keeps internal fragmentation in the last page. Follow-up probe: "every memory access now needs a page-table lookup too, so is memory twice as slow?" No, the TLB caches recent translations; only a TLB miss pays the extra access.
Q33. What happens on a page fault? The MMU traps to the OS, which checks the reference is valid, finds a free frame (or evicts one using a replacement policy), schedules a disk read for the page, updates the page table, and restarts the faulting instruction. This is demand paging: pages load only when touched.
Q34. What is thrashing, and how do you stop it? Thrashing is when processes spend more time servicing page faults than executing, because too many processes are competing for too few frames and none holds its working set. The trap question: CPU utilisation drops, so a naive scheduler admits more processes, which makes it worse. This is the end of the chain that started at Q1: switching and paging are cheap individually, and pile-ups of them are what kill performance. Fixes: working-set-based allocation, page-fault-frequency control, or reducing the degree of multiprogramming.
The rest of the memory chain:
Q35. Internal vs external fragmentation. Internal fragmentation is unused space inside an allocated block, such as the tail of the last page of a process. External fragmentation is free memory scattered into pieces too small to satisfy a request; paging removes it, and contiguous or segmented allocation suffers it.
Q36. Paging vs segmentation. Paging uses fixed-size pages, is invisible to the programmer, and has no external fragmentation. Segmentation uses variable-size logical units (code, stack, heap), is visible to the programmer and good for protection and sharing, but fragments memory externally. Segmented paging takes both halves.
Q37. First fit, best fit, worst fit. First fit takes the first hole large enough and is the fastest. Best fit takes the smallest adequate hole and leaves slivers too small to reuse. Worst fit takes the largest hole so the remainder stays usable, but consumes the big holes you will want later. In practice first fit and best fit both beat worst fit.
Q38. FIFO, LRU, and Optimal page replacement on a given reference string. Simulate frame by frame: FIFO evicts the page loaded earliest, LRU the one unused for longest, Optimal the one needed furthest in the future. Count compulsory faults too, and use Optimal as the lower bound your answer cannot beat.
Q39. Belady's anomaly and which algorithms suffer it. Belady's anomaly is more frames producing more page faults. FIFO can show it; stack algorithms such as LRU and Optimal cannot, because the pages held with k frames are always a subset of those held with k+1.
Q40. Effective access time with a TLB hit ratio. With single-level paging, EAT = hit ratio times (TLB time plus one memory access) plus miss ratio times (TLB time plus two memory accesses), the second access being the page-table read. State your assumption about whether the TLB lookup overlaps the memory access, because that is what the examiner is checking.
Q41. Swapping vs paging. Swapping moves an entire process between memory and backing store; paging moves individual pages on demand, so a process runs with only part of itself resident. Modern systems page, and the word swap survives mainly as the name of the backing area.
Q42. What virtual memory buys you beyond more memory. Isolation and protection between address spaces, sharing (one copy of a library mapped into many processes), copy-on-write, relocation without rewriting addresses, and the freedom to load a program whose linked addresses have nothing to do with where it physically sits.
Q43. Copy-on-write in fork(). The child's page table points at the parent's frames marked read-only instead of copying them. The first write by either side traps, and the kernel copies just that one page. It is why fork immediately followed by exec costs almost nothing.
File system, disk, and quick-fire questions (Q44 to Q50)
These come as warm-ups or closers, and a crisp answer to each is enough:
Q44. What is a system call, and what happens when one executes? It is a controlled entry into kernel mode. The library stub places the call number and arguments where the kernel expects them and executes a trap instruction; the CPU switches to kernel mode, the handler dispatches through the system-call table, the service runs, and control returns to user mode with the result and errno.
Q45. What is an inode, and what does it store? It holds a file's metadata: type, permissions, owner and group, size, timestamps, link count, and pointers to data blocks (direct, then single, double and triple indirect). It does not hold the filename, which lives in the directory entry that points at the inode number, which is what makes hard links possible.
Q46. Compare FCFS, SSTF, SCAN, and C-SCAN disk scheduling. FCFS serves requests in arrival order: fair, poor seek time. SSTF serves the nearest request, which is efficient but starves far cylinders. SCAN sweeps to one end and back, servicing on the way. C-SCAN sweeps in one direction only and jumps back without servicing, which makes waiting times far more uniform.
Q47. Buffering vs caching vs spooling. Buffering absorbs a speed or size mismatch between producer and consumer. Caching keeps a second copy of frequently used data in faster storage. Spooling queues whole jobs for a device that cannot be shared, which is why printing is the standing example.
Q48. Monolithic kernel vs microkernel. In a monolithic kernel the file system, drivers, and IPC all run in kernel space: fast, because calls are function calls, but a fault anywhere can take the system down. A microkernel keeps only IPC, scheduling, and basic memory management privileged and runs services as user processes: more robust and modular, at the cost of message-passing overhead.
Q49. What happens from power-on to login? Firmware (BIOS or UEFI) runs POST and hands over to the bootloader on the boot device; the bootloader loads the kernel and an initial RAM disk; the kernel initialises memory management, drivers, and the root file system, then starts the first user process, init or systemd, which brings up services and finally the login prompt.
Q50. Why does a long-running system slow down? Free memory fragments so large allocations get harder, caches and page tables fill with working sets nobody needs any more, background services and their memory accumulate, and a filling disk scatters new files across distant blocks. The answer that lands is naming the specific resource you would measure first rather than saying reboot it.
How to prepare these 50 questions in two weeks
Do not memorise answers. Learn the five chains: process to thread to context switch, scheduling trade-offs, synchronization to deadlock, paging to thrashing, and the quick-fire layer, so the follow-up probe is a continuation and not an ambush. Explain each answer aloud without notes, then handle one contrast, example or diagram.
Week one starts with Days 1 and 2, Q1 to Q10. Draw the process state diagram (new, ready, running, waiting, terminated), distinguish ready versus waiting, record what a context switch saves and restores, and explain why a thread switch avoids a TLB flush. For scheduling trade-offs on Days 3 and 4, Q11 to Q18, explain the round robin time quantum trade-off, what it optimises, and the convoy effect. Across Days 5 to 7, Q19 to Q31, write a producer-consumer solution with two semaphores and a mutex, list the four deadlock conditions, draw a wait-for graph cycle, and state the safe versus unsafe state distinction.
Week two: Days 8 to 10 cover paging to thrashing, Q32 to Q43. Draw the page-fault path, the working set, and the thrashing feedback loop where falling CPU utilisation tempts a scheduler to admit more processes. On Day 11, give note-free quick-fire answers, Q44 to Q50. On Days 12 and 13, practise Q1, Q2, Q3, Q11, Q12, Q19, Q20, Q21, Q32, Q33 and Q34, and answer every named follow-up probe. On Day 14, run all 50 in order; every answer must be accurate, concise and note-free. Once the fortnight is done, the Placement Preparation category collects the rest of your drive preparation.
If you want the whole subject sequenced for you, Computer Science Fundamentals for Placements by Sanchit Sir covers Operating Systems in about six and a half hours of instructor-led video with company-tagged MCQs (TCS, Infosys, Wipro, Cognizant and more), alongside DBMS, Computer Networks, and Software Engineering, with a day-by-day planner. If you only need OS revision, work the learn module and its question pools directly.
Answer the whiteboard-depth questions out loud, by hand, at least once. An interviewer is not checking whether you have read about thrashing. They are checking whether you can walk there from "what is a process" without being carried.
