Operating Systems Interview Questions for Software Engineers: Processes, Memory, Scheduling, and Concurrency

A textbook answer says that a process has its own address space and threads share memory. An interview-ready answer goes further: it explains what the operating system must save during a context switch, why a page fault can be normal or fatal, how a scheduler balances latency against throughput, and where shared state becomes unsafe.

That is the level software engineers are usually tested at. You do not need to recite every kernel data structure, but you must connect each abstraction to a real behavior: a blocked request, rising latency, memory pressure, starvation, or a race that appears only under load.

Start with PracHub interview questions with written solutions, answer each prompt aloud before reading the solution, and keep asking four questions: what state exists, what changes it, what does the change cost, and what can fail?

Quick answer: what operating systems interviews test

Strong candidates reason from mechanisms, not vocabulary. They can trace a process from runnable to blocked and back, translate a virtual address through a TLB and page table, choose a synchronization primitive from the required invariant, and explain how scheduling policy changes user-visible latency.

The expected depth depends on the role. A general backend interview may stop at processes versus threads, virtual memory, and deadlock. Infrastructure, database, browser, embedded, HFT, and kernel-adjacent roles often continue into copy-on-write, cache effects, priority inversion, memory ordering, and practical diagnostics.

Processes, threads, and context switches

What is the difference between a process and a thread?

A process is primarily a protection and resource boundary. It has an address space and kernel-managed resources such as file descriptors, credentials, signal state, and one or more threads. A thread is an execution context inside that process, with its own program counter, registers, stack, and scheduling state.

Threads in one process normally share code, heap data, and open resources, so communication is cheap but accidental interference is possible. Separate processes provide stronger isolation, but coordination usually needs pipes, sockets, shared memory, or another IPC mechanism. The correct choice depends on isolation, communication volume, failure containment, and runtime support.

What happens during a context switch?

The OS stops one execution context, preserves enough CPU state to resume it, chooses another runnable task, restores that task's state, and transfers control. The direct bookkeeping is only part of the cost. The new task may have colder instruction and data caches, and switching address spaces can affect translation caches depending on the architecture and identifiers available.

Avoid quoting one universal context-switch latency. The cost varies with hardware, kernel, working set, and whether the tasks share an address space. Explain the sources and how you would measure them.

Why can a process be runnable but not running?

Runnable means the task is eligible for CPU time; running means a CPU is executing it now. If there are more runnable tasks than available CPU cores, the scheduler keeps some tasks in run queues. A blocked task is different: it is waiting for an event such as I/O completion, a timer, a lock, or a condition.

This matters in production debugging. Do not conclude "CPU bottleneck" from one load number; inspect per-thread CPU, run-queue pressure, I/O wait, and lock contention.

Virtual memory, paging, and page faults

How does virtual address translation work?

A process issues virtual addresses. The memory-management unit translates them to physical addresses using page tables maintained by the OS. Because a full page-table walk is expensive, the processor caches recent translations in a translation lookaside buffer, or TLB.

On a TLB hit, translation is fast. On a miss, hardware or software walks the page-table hierarchy, checks presence and permissions, and may cache the result. Larger pages can reduce TLB pressure and page-table overhead, but may waste memory and make allocation or compaction harder.

Is every page fault an error?

No. A page fault is an exception that gives the OS a chance to resolve a missing or disallowed translation. A valid demand-paging fault may allocate a zero-filled page or load file-backed data. A copy-on-write fault may create a private writable copy after a process writes to a page it initially shared.

An invalid address or permission violation cannot be resolved normally and may produce a segmentation fault. In an interview, trace the full decision: address lookup, TLB miss if relevant, page-table state, fault handler, possible I/O or allocation, table update, TLB update, and instruction restart.

Stack, heap, and memory-mapped regions

Each thread has a stack for call frames and local automatic storage. Threads share the process heap and other mapped regions, which is why a heap object can be visible to several threads. Memory-mapped regions can represent anonymous memory, files, shared memory, or device mappings.

Do not rely on a universal "heap up, stack down" picture; layout, randomization, runtimes, and architecture change the details. Focus on ownership, lifetime, visibility, and failure behavior.

CPU scheduling interview questions

How do scheduling policies trade fairness, latency, and throughput?

First-come, first-served minimizes policy complexity but can create a convoy behind a long job. Shortest-job approaches improve average waiting time when durations are known or estimated, but long tasks may starve. Round robin improves interactivity by preempting tasks after a quantum, yet a very small quantum increases switch overhead while a very large one approaches FCFS behavior.

Priority scheduling favors important work but needs a starvation strategy such as aging. Real-time policies optimize deadline or priority guarantees rather than ordinary fairness. Modern Linux's fair-class scheduler has been transitioning from CFS toward EEVDF, which uses virtual lag and deadlines to select eligible tasks; this is a useful current example, not a fact every general SWE must memorize.

Preemptive versus cooperative scheduling

With preemption, the scheduler can interrupt a running task so another can execute. This improves responsiveness and prevents a well-behaved system from depending on every task yielding, but shared state can be interrupted at many points. Cooperative scheduling switches when a task explicitly yields or awaits, which simplifies some reasoning but allows a task that never yields to stall peers.

Do not confuse concurrency with parallelism. One core can interleave concurrent tasks; parallel execution needs multiple processing resources. Asynchronous I/O is a programming model, while the runtime and OS still schedule the underlying work.

What are starvation and priority inversion?

Starvation means a task remains ready or waiting but repeatedly loses access to a needed resource. Priority inversion occurs when a high-priority task waits on a lock held by a lower-priority task while medium-priority work keeps preempting the lock holder. Priority inheritance can temporarily raise the holder's effective priority so it can release the resource.

Unlike starvation or inversion, deadlock forms a dependency cycle whose participants cannot progress without intervention.

Concurrency and synchronization

Race condition, data race, and atomicity

A race condition means the outcome depends on timing or ordering. A data race is a narrower language-level condition involving conflicting unsynchronized memory accesses, at least one of which is a write. Even when individual reads and writes are atomic, a compound read-modify-write sequence can violate the application invariant.

Start every concurrency answer by naming the shared state and invariant. Then identify which operations must appear indivisible, what establishes visibility and ordering, and whether blocking is acceptable. "Add a lock" is incomplete until you define the lock's scope, ownership, and contention cost.

Mutex, semaphore, condition variable, or atomic?

A mutex protects a critical section with owner-based mutual exclusion. A semaphore represents a count of permits and can model bounded capacity or resource availability. A condition variable lets a thread sleep until a predicate over protected state may have changed; the predicate must be checked in a loop because wakeups do not prove it is true.

Atomics suit small state transitions with a clear memory-ordering story, but do not automatically protect multi-field invariants. Prefer the simplest primitive that proves correctness.

How do deadlocks happen?

The classic necessary conditions are mutual exclusion, hold-and-wait, no preemption of held resources, and circular wait. Prevention breaks at least one condition. In application code, consistent global lock ordering is often the cleanest defense; alternatives include acquiring all resources together, using timeouts or try-lock with rollback, or redesigning ownership to avoid shared mutable state.

For more race, deadlock, and synchronization examples, read PracHub's concurrency interview guide.

Use the OS answer trace

When the interviewer gives you a scenario, walk through four checkpoints: state, transition, cost, and correctness. This works for a page fault, a blocked mutex, a context switch, or a service whose latency rises under load.

State names the threads, mappings, queues, locks, and ownership. Transition identifies the syscall, fault, wakeup, timeout, or preemption. Cost covers CPU, cache, TLB, I/O, and contention. Correctness closes with the invariant, progress guarantee, and evidence.

Practical OS scenarios interviewers ask

A service uses 100% CPU but throughput falls

Separate user CPU from kernel CPU and inspect per-thread utilization. Look for excessive runnable threads, lock contention, spin loops, allocator pressure, system-call volume, context switches, cache misses, and throttling. More threads can reduce throughput when synchronization and cache movement dominate useful work.

Memory usage grows until the process is killed

Distinguish virtual size, resident memory, page cache, allocator retention, and truly unreachable objects. Check allocation rate, working-set growth, major faults, swap activity, cgroup limits, and OOM evidence. A leak, unbounded cache, fragmentation, or legitimate workload growth require different fixes.

Threads hang even though CPU usage is low

Low CPU with no progress suggests blocking. Capture thread stacks, build a wait-for graph, inspect lock ownership, and check I/O and condition-variable predicates. For a deadlock, identify the dependency cycle; for a lost wakeup or missed condition, reproduce the transition that allowed a waiter to sleep after the state changed.

Practice with PracHub questions

Use the first question as an oral diagnostic, then move into code and debugging. Each complete title below opens the question and written solution directly.

A seven-day operating systems preparation plan

Frequently asked questions

Are operating systems questions common in software engineering interviews?

They are common in infrastructure, backend, database, browser, embedded, HFT, and performance-sensitive roles. General SWE interviews may stop at fundamentals; kernel-adjacent roles expect deeper implementation knowledge.

How deep should I study operating systems for interviews?

Master processes versus threads, context switching, task states, virtual memory, page faults, scheduling, synchronization, races, and deadlocks. Go deeper for kernels, runtimes, storage engines, low latency, embedded systems, or performance engineering.

Do I need to memorize scheduling algorithms?

Know FCFS, shortest-job approaches, round robin, priority scheduling, and basic real-time policies. Predicting response time, throughput, fairness, and starvation matters more than memorizing formulas.

What is the best way to answer an OS interview question?

Define the abstraction, trace one execution, name the cost, inject a failure, and close with the correctness or progress property.

Should I use Linux-specific details?

Use Linux as a concrete example, but label implementation details. Start with the portable concept, then add page tables, copy-on-write, or EEVDF only when they strengthen the answer.

Final takeaway

Operating systems interview questions become manageable when you stop treating processes, memory, scheduling, and concurrency as separate chapters. They are one execution story: a thread accesses memory, enters the kernel, blocks or becomes runnable, competes for CPU time, and coordinates with other work while preserving an invariant.

Practice that story with PracHub's interview question bank. Start with the linked OS diagnostic, then implement and debug the concurrency questions until you can explain not only what works, but why it remains correct under interruption, contention, and failure.

Sources and Further Reading

• Linux Kernel Documentation: Page Tables, MMU, TLB, and Page Faults
• Linux Kernel Documentation: Memory Management Concepts
• Linux Kernel Documentation: EEVDF Scheduler
• Linux Kernel Documentation: Lock Types and Their Rules
• Linux man-pages: POSIX Threads
• The Open Group: pthread_cond_wait
• Operating Systems: Three Easy Pieces

Research note: This guide was checked on August 22, 2026. Operating-system implementations vary by kernel, architecture, runtime, and version; state those assumptions when using implementation-specific details.