Common OS Interview Questions

Operating systems questions show up in almost every systems-level technical interview because they test whether you understand what happens beneath the code you write every day. Interviewers use them to probe your grasp of processes, memory, scheduling, and synchronization — and to see whether you can reason precisely instead of reciting buzzwords. This lesson collects the questions that come up most often, with concise, correct answers you can adapt in your own words during an interview.

A process is an independent unit of execution with its own address space (code, data, heap, stack) and its own set of OS resources such as open file descriptors. A thread is a unit of execution that lives inside a process and shares that process's address space and resources with other threads in the same process, but has its own stack, program counter, and register set. Because threads share memory, communication between them is cheap (just read/write shared variables) but requires synchronization; communication between processes requires explicit IPC mechanisms but gives strong isolation.

Mutual exclusion (at least one resource is held in a non-shareable mode), hold and wait (a process holds one resource while waiting for another), no preemption (a resource can only be released voluntarily by the process holding it), and circular wait (a cycle of processes exists where each waits for a resource held by the next). All four must hold simultaneously for a deadlock to occur; breaking any single one prevents deadlock.

Paging divides physical memory and logical address space into fixed-size blocks called pages and frames, so allocation is easy and there is no external fragmentation, though internal fragmentation can occur within the last page. Segmentation divides a program into variable-size logical units (code, stack, heap) that mirror how the programmer thinks about the program, which makes protection and sharing more natural but reintroduces external fragmentation since segments have varying sizes.

A semaphore is an integer synchronization variable accessed only through atomic wait (P/decrement) and signal (V/increment) operations, used to control access to a resource pool; a counting semaphore can allow more than one holder. A mutex is specifically a binary lock with ownership semantics — only the thread that acquired it may release it, and it is designed purely for mutual exclusion of a critical section, not general signaling between threads.

A page fault is a trap raised by the MMU when a process accesses a page that is marked not-present in its page table, meaning the page is not currently in physical memory. The OS's fault handler locates the required page (in swap or the file system), selects a free frame or evicts a victim frame using a page-replacement algorithm, loads the page into memory, updates the page table, and then resumes the faulting instruction.

The CPU saves the current process's or thread's execution state — program counter, registers, stack pointer, and other CPU state — into its process control block (PCB), then loads the saved state of the next process to run from its PCB, and updates memory-management registers such as the page table base register if switching address spaces. Context switches are pure overhead from the application's point of view; the CPU does no useful work during them, which is why minimizing their frequency and cost matters for scheduler design.

Multiprogramming keeps several jobs in memory so the CPU can switch to another job whenever one blocks on I/O, maximizing CPU utilization on a single processor. Multitasking extends this idea to interactive use, rapidly time-slicing the CPU among multiple tasks so users perceive them as running simultaneously. Multiprocessing means the system has more than one physical CPU (or core), so processes can execute truly in parallel rather than merely being interleaved.

Thrashing occurs when a system spends more time paging pages in and out of memory than executing actual process instructions, because the combined working sets of the running processes exceed available physical memory. It is typically caused by over-committing the degree of multiprogramming; the fix is to reduce the number of concurrently running processes (via a working-set model or load control) rather than adding more processes, which would make it worse.

In preemptive scheduling, the OS can forcibly take the CPU away from a running process — for example when a higher-priority process arrives or a time quantum expires — enabling better responsiveness but requiring careful synchronization to avoid race conditions during the switch. In non-preemptive scheduling, once a process is given the CPU it keeps it until it voluntarily yields, blocks for I/O, or terminates, which is simpler to reason about but can let a long process starve others of CPU time.

A race condition occurs when the correctness of a program depends on the relative timing or interleaving of multiple threads or processes accessing shared data, typically because a critical section is not properly protected. It is prevented by ensuring mutual exclusion around the shared data using mechanisms such as locks, mutexes, semaphores, or monitors, so that only one thread executes the critical section at a time.