Operating System Interview Questions and Answers

OS interviews test whether you understand how the kernel manages hardware for applications—CPU, memory, files, and devices—not whether you memorized every scheduling algorithm name.

The OS is a resource manager and abstraction layer—apps see files and sockets, not raw disk sectors.

Linux operating system interview questions usually assume general-purpose multitasking with preemptive scheduling.

Use one Linux VM to observe fork, zombies, and memory with real commands.

A process is a program in execution—an independent unit with its own virtual address space, resources (file descriptors, credentials), and Process Control Block (PCB) metadata.

When you run ./app, the OS loads code, allocates memory, creates a PCB, and schedules it on the CPU.

A strong answer is:

A process is the OS's container for a running program—own address space and kernel bookkeeping—not just the executable file on disk.

A strong answer is:

Processes isolate memory for safety; threads share memory for speed—I pick processes for isolation boundaries and threads for parallel work inside one app.

Common states:

On Linux, ps STAT column shows R, S, D, Z, etc.

A strong answer is:

I describe the ready-running-waiting cycle and mention Linux ps states—blocked on I/O is waiting, not consuming CPU.

The PCB (or task_struct on Linux) is the kernel's record for a process:

• Process ID (PID), parent PID (PPID)
• CPU registers, program counter
• Memory management info (page tables)
• File descriptor table
• Scheduling state and priority

Context switches save and restore PCB fields.

A strong answer is:

The PCB is how the kernel tracks everything about a process—when we context-switch, we're swapping PCB state so another process can run.

Context switching saves the state of the current process/thread and loads another so the CPU can run different work.

Costs:

• Save/restore registers and program counter
• TLB flush on process switch (virtual address space change)
• Cache pollution (cold caches for new working set)

Frequent switching with tiny time slices can hurt throughput—context switch overhead is why batching work matters.

A strong answer is:

Context switching enables multitasking but isn't free—process switches flush TLB and warm caches, so I reduce unnecessary threads and syscall churn in hot paths.

Zombies consume PID/table slots, not memory of the dead program—many zombies indicate parent not reaping.

ps -eo pid,ppid,stat,cmd | awk '$3 ~ /Z/ {print}'

On a healthy system this often prints nothing; zombies appear briefly when parents omit wait().

A strong answer is:

Zombies are exited children waiting for parent to reap—I fix the parent to call wait or use proper signal handling, not kill zombies individually.

fork() creates a child process—duplicate of parent; copy-on-write makes duplicating memory efficient.

exec() replaces the child's memory image with a new program.

Typical shell pattern: fork → child execs command → parent waits.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid = fork();
    if (pid == 0) {
        printf("child pid=%d\n", (int)getpid());
        return 0;
    }
    if (pid > 0) {
        wait(NULL);
        printf("parent pid=%d reaped child %d\n", (int)getpid(), (int)pid);
    }
    return 0;
}

Running prints child PID then parent reaping message—classic Unix process creation.

A strong answer is:

fork duplicates the process; exec loads a new program in the child—shells and servers use this pair to spawn commands without blocking the parent forever.

Choose based on throughput, isolation, and persistence needs.

A strong answer is:

Pipes and sockets for streams; shared memory when bandwidth matters but I add mutexes—signals for lifecycle events like graceful shutdown.

Scheduling selects which ready process/thread runs on the CPU when multiple contenders exist.

Goals:

• CPU utilization — keep CPU busy
• Throughput — jobs completed per time
• Turnaround / waiting time — user-perceived latency
• Fairness — avoid starvation

A strong answer is:

Scheduling picks the next runnable task—policies trade fairness, latency, and throughput depending on desktop, server, or real-time workload.

Round Robin suits time-sharing interactive systems.

A strong answer is:

FCFS is simple but unfair to short jobs; RR with a reasonable quantum gives interactive responsiveness; SJF optimizes average wait if job lengths are known.

Timer interrupts enable preemption—kernel regains control for scheduling.

A strong answer is:

Modern general-purpose OSes are preemptive—the scheduler can interrupt a running task on timer tick or higher-priority wake, which keeps the system responsive.

Each process has a priority—highest priority ready process runs first.

Problems: starvation of low-priority tasks.

Aging gradually increases priority of waiting processes to fix starvation.

Linux nice values (-20 to 19) influence CFS weight—not raw fixed-priority preemptive except RT classes.

A strong answer is:

Priority scheduling favors important work but needs aging to avoid starvation—on Linux nice tweaks CFS weight rather than strict fixed-priority queues for normal tasks.

CFS (default for normal tasks) models an ideal fair CPU where all runnable tasks would get equal time.

• Tracks virtual runtime (vruntime) per task
• Runnable tasks in a red-black tree keyed by vruntime
• Always runs task with lowest vruntime
• Nice values adjust weight (lower nice → more CPU share)

Real-time policies SCHED_FIFO / SCHED_RR bypass CFS for RT tasks.

A strong answer is:

CFS picks the task that has received least CPU time proportionally—vruntime on a red-black tree—with nice values biasing share, not a fixed time quantum like classic RR.

MLFQ uses multiple queues with different priorities; processes move between queues based on behavior:

• CPU-bound jobs demoted to lower priority
• I/O-bound interactive jobs stay higher

Adapts without knowing job length in advance—teaching concept; Linux CFS differs but interviewers use MLFQ to test adaptive scheduling intuition.

A strong answer is:

MLFQ separates interactive from CPU-bound by promoting I/O waiters and demoting CPU hogs—it's the classic adaptive scheduler taught even though Linux uses CFS in production.

Virtual memory gives each process an illusion of a large, private, contiguous address space while physical RAM is shared and limited.

Benefits:

• Isolation — processes cannot access each other's memory
• More memory than RAM — swap/paging to disk
• Simplified linking — each program can use similar virtual addresses
• Shared libraries — map same physical pages read-only

A strong answer is:

Virtual memory isolates processes and lets the OS overcommit address space with paging—apps see private memory; the MMU maps to physical frames.

Memory divided into fixed-size pages (virtual) mapped to frames (physical) via page tables.

MMU translates virtual address → physical frame on each access.

A strong answer is:

Paging splits memory into fixed pages mapped by page tables—the MMU translates every access, enabling protection and non-contiguous physical allocation.

A page fault occurs when a process accesses a virtual page not present in RAM (or invalid).

Handling sequence (simplified):

1. CPU traps to kernel
2. OS checks if access is legal (segfault if illegal)
3. If valid but not in RAM—page in from disk (major fault) or allocate zero page
4. Update page table, restart instruction

Minor fault — page in memory but not mapped yet; major fault — disk I/O required.

A strong answer is:

Page fault is MMU saying this mapping isn't ready—the kernel loads the page from disk or kills the process on illegal access; major faults are expensive disk paths.

The TLB is a CPU cache of recent virtual→physical translations.

Process context switch often flushes TLB—another context-switch cost.

A strong answer is:

TLB caches page table entries—misses add latency; that's why process switches hurt more than thread switches and why huge pages help TLB pressure.

Many systems use paging with segment-like concepts in higher-level runtimes.

A strong answer is:

Paging is fixed-size and avoids external fragmentation; segmentation matches logical program parts—modern OSes rely on paging with MMU protection bits.

Paging suffers internal; segmentation suffered external—compaction or paging mitigates.

A strong answer is:

Internal fragmentation is wasted space inside allocated units; external is free gaps between allocations—paging trades internal waste for simpler management.

When RAM is full and a new page needed, OS evicts a frame:

Linux uses refined policies (LRU-like lists, active/inactive) not naive FIFO.

A strong answer is:

Optimal is the benchmark; LRU approximates locality; real Linux uses refined LRU classes and swap tuning—not textbook FIFO alone.

Thrashing occurs when the system spends more time paging than executing—working set exceeds RAM, constant page faults, collapse in throughput.

Causes: too many processes, oversized heaps, insufficient RAM.

Fixes: add RAM, reduce concurrency, tune swap, fix memory leaks, use cgroups limits.

Connects to JVM GC + swap storm scenarios in senior loops.

A strong answer is:

Thrashing is the OS paging constantly instead of running useful work—I detect it via high major faults and swap I/O, then reduce memory pressure or add RAM.

Swapping moves entire process or pages between RAM and swap space on disk.

Modern Linux emphasizes paging over whole-process swap-in/out, but swap still backs anonymous pages under pressure.

free -h shows used swap; high swap with slow performance signals memory pressure.

A strong answer is:

Swap extends RAM with disk—acceptable for idle pages but disastrous when hot working sets live on swap; I watch swap I/O and major faults in incidents.

mmap maps file contents (or anonymous memory) into a process's virtual address space—reads/writes can hit the page cache like memory.

Used for:

• Fast file access
• Shared libraries loaded by dynamic linker
• Databases and engines mapping data files

See also language-level memory in C and C++ interviews.

A strong answer is:

mmap maps files into virtual memory—access goes through page cache and MMU, which is how shared libraries and many databases avoid explicit read/write per access.

A race condition occurs when correctness depends on unordered timing of threads/processes accessing shared mutable state without proper synchronization.

Example: two threads increment a counter—both read 5, write 6 instead of 7.

Fix: mutex, atomic operations, or immutable data structures.

A strong answer is:

Race means shared mutable state without coordination—I serialize with mutexes or use atomics when the operation is simple enough.

The critical section is code accessing shared resources that must not run concurrently by multiple threads without rules.

Requirements for solution:

• Mutual exclusion
• Progress — someone enters if no conflict
• Bounded waiting — no indefinite postponement

A strong answer is:

Critical section is the shared-resource code path—mutexes ensure only one thread executes it at a time while avoiding deadlock and starvation where possible.

Binary semaphore ≠ mutex in strict ownership semantics.

A strong answer is:

Mutex is for exclusive access with owner unlock; counting semaphore limits N concurrent users—I'd mutex a bank balance update and semaphore a connection pool.

A monitor is a high-level synchronization construct—mutex + condition variables bundled so only one thread is active inside the monitor at a time.

Java synchronized methods and wait()/notify() implement monitor-style sync—see Java part 2 threading.

A strong answer is:

Monitors combine mutual exclusion with condition waits—Java synchronized blocks are the textbook monitor pattern most app developers actually use.

Producers add items to a bounded buffer; consumers remove them.

Needs:

• Mutex for buffer structure
• Counting semaphores or condition variables for empty and full slots

Classic teaching problem for semaphores and monitors.

A strong answer is:

Producer-consumer needs mutual exclusion on the buffer plus signaling when slots are empty or full—semaphores or condition variables prevent busy-waiting.

Deadlock is a state where processes/threads are blocked forever, each waiting for a resource held by another in a cycle.

Example: Thread A holds lock1 waits lock2; Thread B holds lock2 waits lock1.

A strong answer is:

Deadlock is circular wait with no forward progress—I detect cycles in lock graphs or prevent with ordering, not hope timeouts alone fix design bugs.

All four must hold simultaneously:

Break any one to prevent deadlock—common: lock ordering breaks circular wait.

A strong answer is:

I list all four Coffman conditions, then show how global lock ordering breaks circular wait—the prevention pattern I use in real code reviews.

Databases use detection + rollback; kernels often favor prevention in driver paths.

A strong answer is:

Prevention via lock ordering in app code; databases detect and rollback; avoidance like Banker's is taught for theory—I explain which fits kernel vs application context.

Banker's algorithm is deadlock avoidance—before granting a resource request, simulate allocation and ensure the system stays in a safe state (some completion order exists).

Used teaching safe vs unsafe states; less common in every production allocator but frequent in exams.

A strong answer is:

Banker's algorithm grants requests only if a safe sequence exists afterward—it's avoidance theory I use to explain safe states even if Linux allocators don't implement it literally.

A strong answer is:

Deadlock is circular permanent block; starvation is indefinite postponement—aging and fair scheduling fix starvation without full deadlock.

System calls (read, write, fork) transition to kernel mode safely—trap/interrupt mechanism.

A strong answer is:

Apps run user mode; syscalls trap into kernel mode for privileged work—that's the boundary protecting hardware and other processes.

Practice on Ubuntu—see shell scripting interviews.

ps -o pid,ppid,stat,nlwp,cmd -p $$

Shows current shell PID, parent, state, and thread count (nlwp)—links process theory to the terminal.

A strong answer is:

I tie ps STAT column to zombie/blocked states, vmstat to faults and context switches, and free to swap pressure—commands make OS theory observable.

Containers use Linux namespaces (pid, net, mount, user) and cgroups for limits—isolation without full second kernel.

A strong answer is:

VMs virtualize hardware with guest kernels; containers share one kernel with namespaces and cgroups—isolation is lighter but the kernel is a shared trust boundary.

cgroups (control groups) limit and account CPU, memory, I/O for process groups—foundation of Docker/Kubernetes resource limits.

OOM killer may terminate processes exceeding memory cgroup limit before thrashing entire host.

A strong answer is:

cgroups cap CPU and memory per service—Kubernetes limits map to cgroup knobs, preventing one pod from thrashing the node.

Diagnosis path:

1. top — CPU vs I/O wait (wa) vs steal
2. Uninterruptible sleep (D state) — blocked on disk/NFS
3. iostat — disk saturation
4. Runnable queue vs blocked threads
5. Memory — swap thrashing causing I/O wait

High load can mean many blocked tasks, not CPU burn.

A strong answer is:

High load with low CPU often means I/O wait or uninterruptible disk sleep—I check ps STAT D, iostat, and swap, not only CPU percentage.

Linux OOM killer selects a process when memory overcommit cannot be satisfied—free RAM + swap insufficient, cgroup limit hit, or aggressive allocation.

Kernel logs: dmesg | grep -i oom

Mitigation: tune heap, add RAM, cgroup limits, fix leaks, reduce cache footprint.

Links JVM heap sizing to OS paging—see Java interviews.

A strong answer is:

OOM means kernel chose to kill a process to reclaim memory—I read dmesg for victim PID, then fix leak, sizing, or cgroup limits rather than only restarting the app.

Checklist:

• Process vs thread memory diagram
• Process states + zombie/orphan
• Context switch cost and TLB
• FCFS, RR, CFS one-liners
• Virtual memory, page fault sequence
• TLB, thrashing, swap
• Mutex vs semaphore
• Four Coffman conditions + lock ordering fix
• Linux — ps, top, free, vmstat
• Containers — namespaces + cgroups
• Two scenarios — high load, OOM
• Shell scripting command refresh
• C and C++ if systems role

A strong answer is:

I whiteboard process vs thread and page fault flow, recite Coffman with a prevention example, then walk one Linux incident story with the commands I actually ran.