Operating System Interview Questions for 2026

Answer: It is the layer between hardware and everything you run, and its core jobs are turning one CPU into many through scheduling, one RAM into protected address spaces through virtual memory, and raw devices into files, sockets, and pipes programs can open. When it does those jobs well, applications never see each other or the hardware directly. That framing, resources protected and multiplexed, is what operating system interview questions at this level are checking for.

Answer: The kernel is the privileged core that owns scheduling, memory, drivers, and the system call interface. The shell is an ordinary userland program that reads your commands and starts processes on your behalf. The practical difference: a shell crash costs you a terminal, a kernel crash takes the whole machine down with a panic, and that asymmetry is the opener most operating system interview questions build on.

Answer: Firmware (BIOS or UEFI) initializes the hardware and hands the machine to a bootloader; the kernel takes over, owns resources, and starts PID 1; userland is everything above the syscall line: your daemons, CLIs, and libraries. This trio opens many operating system interview questions because it checks whether you know which layer a given bug actually lives in.

Answer: A program in execution: code mapped into a private address space, open file descriptors, credentials, and a kernel bookkeeping entry, identified by a PID. Two processes are isolated by default; neither can read the other’s memory or files without permissions or help from the kernel. Isolation is the property the definition exists to state.

Answer: A process owns an address space; a thread is a schedulable unit inside one, sharing that address space, heap, and open files with its siblings while keeping its own stack and registers. Threads talk through shared memory at near-zero cost but need locks; processes are safe from each other but must pay for IPC. That trade is the single most repeated idea in operating system interview questions, so deliver it cleanly.

Answer: A program is bytes on disk: an executable image with no life of its own. A process is that image loaded and running, with state, memory, and a PID. One program can spawn a thousand processes, each with the same code but entirely separate execution, which is exactly how your web server serves many users from one binary.

Answer: The system that gives each process its own private address space and maps it onto physical RAM through page tables. It buys three things: isolation between processes, the ability to run programs larger than physical memory, and cheap tricks like shared libraries mapped into every process at once. Most memory topics in operating system interview questions are follow-ups to this one definition.

Answer: Two mechanisms combine. Allocations only reserve address space; pages are actually created when first touched, a laziness called demand paging. And cold pages can be evicted to swap or dropped if they are file-backed, freeing RAM while the addresses stay valid. The caveat worth adding: this overcommit means an allocation can succeed and blow up later, which is how out-of-memory surprises are born.

Answer: Disk space holding anonymous memory the kernel has paged out under pressure. Using some swap is normal housekeeping, not an emergency; what matters is whether the machine is actively swapping in and out, which you see in the si and so columns of vmstat. Confusing swap usage with swap thrashing is the classic error this question exists to catch.

Answer: It is the CPU telling the kernel that a memory access hit a page with no valid mapping. A minor fault is fixed in RAM: the page is already in the page cache or needs a copy-on-write break. A major fault requires reading from disk, which costs microseconds to milliseconds. Faults are normal; a working system takes thousands of minor faults per second. Sustained major faults are the red flag, and that distinction is what operating system interview questions here are really grading.

Answer: The kernel choosing which runnable task gets each core and for how long, balancing fairness, latency, and throughput. Dozens of tasks may be runnable at once on a machine with eight cores, and scheduling is the discipline that makes all of them appear to progress. Every tuning knob from nice values to cgroup weights ends up acting on this one decision.

Answer: Preemptive means a timer interrupt lets the kernel yank the CPU away from a task mid-run; cooperative means a task keeps the CPU until it voluntarily yields. Every general-purpose OS today is preemptive, which is why one busy loop cannot freeze your laptop. The historical exception is worth a sentence: early Windows and classic Mac OS were cooperative, and one hung app hung everything.

Answer: The kernel saving one task’s registers and state, loading another’s, and transferring control, usually with a mode change along the way. There is a direct cost, microseconds of bookkeeping, and an indirect one: CPU caches and TLB entries for the old task go cold. High context-switch rates under load usually mean too many runnable threads or lock churn, which is why this small mechanism anchors so many operating system interview questions about latency.

Answer: R is running or runnable, S is sleeping on an event that will arrive soon, D is uninterruptible sleep, usually I/O the kernel cannot abort, Z is a zombie awaiting reaping, and T is stopped by job control. The two with teeth are D, which ignores every signal including SIGKILL, and Z, which is already dead and waiting for its parent to collect it. Reading states rather than guessing is what these operating system interview questions train.

Answer: The kernel assigns each process a PID, its handle for signals, waits, and /proc entries. PID 1 is init, systemd on modern distributions: the first userspace process that starts everything else, adopts orphans, and ignores signals nobody explicitly handles, which is why killing PID 1 takes special intent. Losing PID 1 means losing the machine, and interviewers like that consequence.

Answer: A background service process with no controlling terminal, started at boot or on demand and supervised by PID 1: sshd, nginx, cron. The defining property is detachment, it keeps running after you log out because nothing ties it to your session. On modern systems the systemd unit file is the contract that makes a daemon well-behaved.

Answer: A zombie is a process that already exited; its parent has not read the exit status, so a stub entry remains in the process table. An orphan is a live process whose parent died; the kernel re-parents it to PID 1, which reaps it when it exits. Zombies cost a table entry, not memory, and the cure is always fixing the parent, two facts that answer most operating system interview questions on this pair.

Answer: An asynchronous notification with a number and a default action: terminate, core dump, stop, or ignore. Programs can catch signals to clean up, block them temporarily, or ignore them, with SIGKILL and SIGSTOP as the untouchable exceptions. Signals are how kill, job control, and graceful shutdowns all work, which makes this small topic the backbone of half the operational rounds in operating system interview questions.

Answer: A per-process integer indexing the kernel’s table of open files. Everything is a file on Unix-like systems, so descriptors cover regular files, sockets, pipes, and devices uniformly. Counts are limited per process, the classic default of 1024 raising into the millions on tuned servers, and a daemon that leaks descriptors dies with too many open files, which is how this definition becomes a war story.

Answer: File descriptors 0, 1, and 2, inherited by every new process from its parent. Redirection is not shell magic: the shell duplicates those descriptors to point at files or pipes before the program even starts. The practical consequence: a daemon with nowhere to write can block or drop output, so services rewire these three deliberately, and that detail is what this question is fishing for.

Answer: A one-way byte stream between two descriptors, buffered by the kernel, typically connecting a parent and child after a fork, which is how ps aux | grep nginx works. A named pipe, or FIFO, gives unrelated processes the same channel through a filesystem name. Pipes block the writer when full and the reader when empty, and that backpressure is a feature, not a flaw.

Answer: A bidirectional endpoint for communication that, unlike a pipe, works equally well across machine boundaries. Unix domain sockets do the same job locally with lower overhead and filesystem permissions, which is why Docker and PostgreSQL default to them for local traffic. Choosing socket versus pipe versus shared memory is a standard follow-up in operating system interview questions about IPC.

Answer: The structure that turns raw disk blocks into named, permissioned, hierarchical files, tracking metadata in structures like inodes and data in blocks. Linux stacks them all under one VFS interface, so ext4, XFS, and NFS present the same API to programs. That abstraction sentence, many implementations behind one interface, is the answer operating system interview questions expect here.

Answer: A block device, like a disk, moves fixed-size blocks, supports random access, and feeds the page cache. A character device, like a terminal or /dev/null, is a byte stream with no random access. The distinction decides how the kernel caches and schedules I/O, which is why asking it is a cheap way for interviewers to check whether you know where your data path starts.

Answer: Partitioning carves a disk into regions with a table such as GPT; formatting, or mkfs, builds a filesystem structure inside one region; mounting grafts that filesystem into the directory tree at a mount point. A disk is usable only after all three, and automation that skips a step produces the classic device is busy or wrong fs type errors this question quietly tests.

Answer: Buffering absorbs differences in size and timing between producer and consumer, smoothing writes into efficient chunks. Caching keeps copies of data likely to be reused, turning slow reads into fast ones. The Linux page cache does both for disk I/O, which is why free -h shows a big buff/cache column on a healthy machine and why that memory is available, not wasted, which is the pivot most operating system interview questions here take.

Answer: Registers, then L1, L2, and L3 caches, then RAM, then disk: each level down is vastly larger and orders of magnitude slower, nanoseconds to hundreds of microseconds. The hierarchy explains why cache-friendly access patterns matter, why a page fault is catastrophic by CPU standards, and why adding RAM often speeds systems more than adding cores. Naming a couple of real latencies is what makes this answer land in operating system interview questions.

Answer: A group of tasks where each one holds a resource the next one needs, so all of them wait forever with nothing able to proceed. Two transactions each holding a row lock the other wants is the canonical database case. Deadlocks differ from ordinary slowness in one way that matters operationally: no amount of waiting helps, which is why timeouts and lock ordering exist, the two fixes operating system interview questions expect you to name unprompted.

Answer: A bug where correctness depends on the timing or interleaving of concurrent operations: two threads both read a counter, both increment, both write, one increment vanishes. Races are the worst class of bug to debug because they are rare, load-dependent, and often vanish under a debugger. That is why interviewers pair this question with locks, and why a one-line mutex fix is the expected follow-up.

Answer: A mutual-exclusion lock around a critical section: only the holder may enter, everyone else waits. Threads share memory, and shared read-modify-write sequences must be atomic or they interleave into races. One caveat earns credit: locks protect invariants, not code, so two separate locks guarding related data can still produce inconsistent state, the seed of most deadlock follow-up questions.

Answer: CPU-bound tasks burn cycles: compression, encryption, video encoding. I/O-bound tasks spend their lives waiting: web backends on databases, log shippers on disks and networks. The classification decides the remedy: more cores or better algorithms for the first, more concurrency or async I/O for the second. It is a standard early entry in operating system interview questions because it tests whether tuning advice gets aimed at the right bottleneck.

Answer: Concurrency is dealing with many tasks in one timeframe, interleaving or overlapping; parallelism is executing many at the same instant, which requires multiple cores. A single-core machine can be fully concurrent and never parallel, and an event loop is concurrent on one thread. The distinction predicts scaling: parallelism ends at core count, concurrency does not, which is the sentence operating system interview questions here are listening for.

Answer: RAID 0 stripes data across disks for speed and capacity but loses everything if one disk dies. RAID 1 mirrors, tolerating one disk per pair. RAID 5 stripes with distributed parity, tolerating one disk; RAID 6 adds a second parity and tolerates two. RAID 10 combines mirroring and striping for fast, expensive safety. State the trade, performance versus capacity versus tolerance, and you have answered this staple of operating system interview questions.

Answer: RAID 1 when write latency and simple recovery matter most: rebuilds are a straight copy, and hot spare disks take over cleanly. RAID 5 when capacity efficiency matters: three disks give two usable instead of one. The cost is the parity write penalty and the fact that rebuilding a large degraded array reads every surviving disk, which is how degraded arrays lose second disks. Explaining that rebuild risk is the detail operating system interview questions on RAID actually score.

Answer: The logical volume manager pools disks as physical volumes into volume groups, then carves flexible logical volumes that carry filesystems. The wins: grow a filesystem online with lvextend plus a resize, take snapshots for consistent backups, and add capacity without repartitioning. LVM is the layer that turns fixed disks into resizable storage, and saying that sentence plus one concrete win is enough here.

Answer: Firmware is code burned into hardware that runs before any OS: it initializes CPUs, memory, and devices, then finds a bootloader. BIOS is the legacy 1980s interface with 16-bit real mode and MBR limits; UEFI is its modern replacement with GPT support, secure boot, and a real pre-boot environment. Boot-chain operating system interview questions usually start here, and the MBR 2 TiB disk limit is the detail that shows you have touched old hardware.

Answer: Registers and pointers are 64 bits wide, giving a practically unlimited virtual address space instead of 32-bit’s 4 GiB per process ceiling. It also means wider pointers and cache lines, slightly larger data structures, and the requirement that kernel and userland match. The interview-relevant consequence: a 32-bit build on a 64-bit kernel can exist, but no single process of it can address beyond 4 GiB no matter how much RAM you add, a ceiling operating system interview questions love to probe.

Answer: The controlled doorway from user code into the kernel: read, write, open, mmap, fork. User mode has no direct hardware access, so every privileged operation becomes a syscall trap. Programs rarely invoke it directly; libc wraps it, which is why strace shows the wrappers’ underlying calls. Counting syscalls per request is a real performance technique, and mentioning it is a strong close to this staple of operating system interview questions.

Answer: fork() duplicates the calling process: the kernel copies the task struct, shares pages copy-on-write, and both executions continue from the same point, distinguished only by the return value. execve() then replaces the current image with a new program, keeping the PID but rebuilding the address space. Shells combine them: fork, wire descriptors in the child, exec the target. Adding that threads come from clone() with sharing flags instead of full forks shows where the mechanism generalizes.

Answer: The kernel saves the outgoing task’s register state and FPU context into its task struct, updates the memory map, loads the next task’s, and resumes it. Costs split in two: direct work of a few microseconds, and indirect damage as TLB and CPU cache entries for the old task go cold, which the next task pays for in misses. pidstat -w 1 separates voluntary switches, blocking on I/O or locks, from involuntary ones, which indicate the scheduler is forcing turns because CPU demand exceeds supply, and reading that split is what operating system interview questions here test.

Answer: Modern kernels use EEVDF, evolution of CFS: every task accumulates virtual runtime weighted by its nice value, and the scheduler picks the task with the most entitlement, with fairness computed per runnable entity and latency slots deciding preemption. The important claim for interviews: nice values scale shares, they do not impose hard limits, and idle cores change everything because a nice-19 job still takes an idle core immediately. cgroup CPU weights apply the same logic to groups, which is how containers share a host.

Answer: FCFS runs tasks in arrival order: simple, and deadly for latency because one long job delays everyone, the convoy effect. Shortest job first minimizes average wait but needs knowing the future, so it survives as an idea rather than a general scheduler. Round robin gives each task a timeslice in turn, trading a little throughput for interactive fairness. Priority scheduling runs the most important first, but pure versions starve the rest, which is why real designs add aging. Nearly all operating system interview questions on scheduling are really asking whether you know each scheme’s failure mode.

Answer: Several queues with different priorities and timeslices; new tasks enter high, and tasks that burn their whole slice are demoted while tasks that block often are promoted. The beauty is that it learns behavior without being told: interactive tasks that yield quickly float up, CPU hogs sink. That automatic adaptation is why the idea underlies classic Unix scheduling and why it is the expected answer when operating system interview questions ask how a system can favor interactive work without configuration.

Answer: Nice values, -20 to 19, live in the normal scheduling class and bias shares of CPU among competing tasks; only root can go negative. Real-time classes, SCHED_FIFO and SCHED_RR with priorities 1 to 99, preempt all normal work and run until they block or are preempted by higher RT. The operational caveat: an RT task that spins can starve every normal task including watchdogs, so kernels provide RT throttling, and production boxes treat RT admission as a deliberate decision, not a tuning accident.

Answer: The virtual address splits into page number and offset. The MMU uses the page number to index the page tables the kernel maintains, walks multiple levels on x86-64, and combines the resulting frame number with the offset. Permission bits are checked along the way, and any failure, not present, insufficient rights, raises a page fault for the kernel to resolve. Saying that the offset passes through unchanged and that every step is hardware speed with kernel-maintained tables is what this question wants.

Answer: Space. A flat table for a 48-bit address space at 4 KiB pages would need gigabytes of table per process, almost all of it describing untouched memory. A four-level radix tree allocates only the branches actually in use, so a process using a few hundred megabytes carries a few pages of table. The trade is that translation now needs up to four memory reads, which is precisely why the TLB from the next question exists. Explaining that causality chain, tables to walks to TLB, is the core of operating system interview questions on translation.

Answer: The translation lookaside buffer is a small cache inside the CPU holding recent virtual-to-physical translations. A hit resolves an access in about a cycle; a miss forces the hardware to walk the page tables, costing tens to hundreds of cycles and potentially several memory accesses per level. Heavy miss rates from random access over huge address ranges can visibly slow software, which is why huge pages and cache-conscious data layout matter. Every operating system interview question about memory performance eventually lands here.

Answer: TLB entries are tagged with an address space, so switching processes invalidates the translations of the old one unless the hardware supports address-space identifiers like PCID on x86-64 or ASID on ARM, which keep entries from multiple processes resident. Without that support, every process switch starts with a cold TLB and a storm of page table walks. This indirect cost is why high context-switch rates depress throughput more than the raw switch time suggests, and stating that order of magnitude is what separates strong answers.

Answer: Pages of 2 MiB or 1 GiB instead of 4 KiB, so one TLB entry covers vastly more memory and walks drop dramatically, which is why large-memory workloads like databases and JVMs often gain. The costs: internal fragmentation when allocations do not fill a huge page, and slower demand paging since more must be moved per fault. Transparent huge pages add unpredictability, their defrag and allocation stalls hurt latency-sensitive services, which is why many DBAs disable THP explicitly. Knowing both directions is the whole answer.

Answer: The CPU raises fault 14 with the faulting address. The kernel checks the address against the process’s VMAs: not mapped at all means SIGSEGV. Legal address, then classify: the frame may already be in the page cache, minor fault, map it and resume; it may need copy-on-write, break the sharing and resume; or it must be read from swap or the backing file, major fault, so the task sleeps on I/O and the scheduler picks someone else. When the read completes the page is mapped and execution resumes at the same instruction. That last detail, the instruction retries, is the detail that separates rehearsed candidates in operating system interview questions.

Answer: Per process, ps -o min_flt,maj_flt,maj_delta -p PID or /proc/PID/stat fields 10 and 12; system-wide, vmstat 1 and sar -B, where majflt/s is the dangerous column. Minor faults are part of normal lazy allocation and copy-on-write, so a busy server takes millions per second without concern. Major faults mean disk was involved: some are warmup, but sustained rates on a mature workload mean the working set does not fit, and that reading of the numbers is exactly what the question is testing.

Answer: The kernel maps address ranges immediately but backs them with no real frames; pages materialize on first touch via minor faults. A malloc of 10 GiB therefore costs microseconds of bookkeeping, not gigabytes of RAM, and untouched pages never consume anything. The operational flip side is that an application’s memory use is discovered under load, not at startup, which is why capacity problems appear at peak traffic and why that implication is the second half of a good answer.

Answer: The kernel lets two mappings point at the same physical frames marked read-only; a write triggers a fault, and only then does the kernel copy the page and remap it privately. This is how fork() duplicates a multi-gigabyte process in microseconds and how zram and snapshot systems deduplicate. The caveat worth volunteering: after fork, a busy parent and child gradually copy the whole working set, so fork-heavy designs pay COW costs later instead of upfront, a classic profiler surprise and a favorite follow-up in operating system interview questions.

Answer: LRU evicts the page least recently used, which is a good recency predictor, but exact LRU needs updating a list on every memory access, far too expensive in software and done nowhere. Clock, or second chance, approximates it: pages carry an accessed bit, a hand sweeps clearing bits and evicting the first page whose bit is already clear, so one bit per page and periodic sweeps approximate recency at trivial cost. Real kernels add active and inactive lists, which is Linux’s refinement, and mentioning that evolution is the credit-earning sentence.

Answer: Against watermark levels per zone: above high, nothing happens; below it, kswapd wakes to reclaim in the background; below min, allocations stall synchronously. Reclaim order is cheap first: drop clean page cache, write back and reclaim dirty pages, then swap out anonymous pages if swap exists, and only when reclaim fails does the OOM killer decide. /proc/zoneinfo and sar -B show where a box sits in that ladder. Describing the ladder instead of jumping straight to the OOM killer is what this entry in operating system interview questions is really grading.

Answer: mmap maps a file or anonymous region into your address space so memory accesses become file accesses through the page cache. It wins for random access to large files, shared memory between processes, and loading executables and shared libraries, which is how every binary you run arrives. It loses for sequential streaming, where plain read with a big buffer is simpler and more predictable, and a mapped write with no msync survives crashes only as long as the kernel does. Choosing by access pattern is the answer interviewers want.

Answer: Mutual exclusion, the resource is held exclusively; hold and wait, a task keeps resources while blocking for more; no preemption, resources cannot be forcibly taken; circular wait, a cycle of tasks each waiting on the next. All four must hold simultaneously, so breaking any one prevents deadlock. This quartet is the theoretical spine of operating system interview questions on locking, and interviewers expect you to convert each condition into a concrete practice: scoped critical sections, global lock ordering, timeouts.

Answer: Prevention breaks one of the four conditions structurally, such as acquiring all locks upfront or enforcing a global ordering, paying in rigidity or serialization. Avoidance checks each allocation against a safety condition, the Banker’s algorithm being the textbook form, and is rarely practical because you must know future demands. Detection lets deadlocks form and hunts cycles periodically, which is what database engines do, then recovery kills a victim or aborts a transaction. Naming which strategy your database actually uses is the move that turns this from theory into the answer senior operating system interview questions want.

Answer: Deadlock: everyone waits, nothing moves, CPU is idle. Livelock: everyone is actively working, usually retrying in response to each other, and still nothing progresses, like two people repeatedly stepping aside in a corridor. Starvation: the system moves, but one task never gets its turn because others always win scheduling or locking races. Diagnosis differs accordingly: stacks frozen in place indicate deadlock, high CPU with zero progress indicates livelock, and healthy throughput with one unlucky client indicates starvation.

Answer: A mutex is ownership: one holder, and only it may release. A counting semaphore is signaling capacity: N permits, and any task may give one back, which fits resource pools and producer-consumer bounds. A condition variable is waiting for a predicate: threads sleep until another thread signals that state changed, always paired with a mutex and a loop against spurious wakeups. The common interview trap is using a semaphore as a lock; it works until someone else releases it and your mutual exclusion silently evaporates.

Answer: A spinlock burns CPU polling until the lock frees, so it wins only when the wait is shorter than a couple of context switches: kernel critical sections, a few instructions in hot data paths. A blocking lock sleeps immediately and lets the scheduler use the CPU elsewhere, which wins for anything userland touches, because waits there are measured in microseconds at best. The rule of thumb to state: spin when hold times are nanoseconds, block when they might exceed a switch, and never spin on a single-CPU box holding preemption off, a classic exam trick.

Answer: Libc places the call number and arguments in registers and executes the trap instruction, syscall on x86-64. The CPU switches to ring 0 at a fixed entry point, the kernel validates the pointer arguments against the caller’s address space, dispatches through a table to the handler, runs it, and returns with a result code that libc converts to return values and errno. That validation step is why kernel bugs are security bugs, and timing syscalls with strace -c is the observable half of this answer.

Answer: A hardware signal that suspends the current instruction stream and vectors into a kernel handler: disks signaling completion, NICs announcing packets, the timer demanding a scheduling decision. Handlers must be fast because they run at elevated priority, so kernels split work: the top half acknowledges the device and does the minimum, deferring the bulk to softirqs or tasklets that run with interrupts enabled. /proc/interrupts shows counts per CPU, and skews there explain more single-core saturation stories than any application profiler, the operational hook operating system interview questions hang this topic on.

Answer: Hard interrupts are device-driven and preempt everything, the top half that must acknowledge hardware. Soft interrupts are kernel-deferred work, packet processing, block I/O completion, timers, executed with interrupts enabled and visible as %soft in mpstat or si in top. The operational angle: on high packet rates, one CPU can saturate doing softirq work while others idle, which is why NIC multiqueue and RSS spreading exist. Mapping a latency complaint onto softirq saturation is precisely what intermediate operating system interview questions here are probing.

Answer: Direct memory access lets a device move data to or from RAM itself while the CPU does other work; without it, the CPU would copy every byte in a loop, burning cycles on what is fundamentally a memcpy. The kernel programs the controller with a descriptor list, the device transfers, then raises one interrupt to report completion. This is why a big sequential disk copy shows near-zero CPU, and why zero-copy techniques like sendfile matter: eliminating CPU copies across the syscall boundary compounds with DMA rather than replacing it.

Answer: libc traps into the kernel; the VFS finds the file’s inode; the page cache answers immediately if the page is resident, which is the common case. On a miss the kernel allocates a page, submits a block request through the block layer and its scheduler to the driver, the device fetches via DMA, and a completion interrupt wakes the waiting task, which resumes with the data. That path explains three observations at once: warm reads are memory-speed, cold reads are disk-speed, and iostat showing the device while the app sleeps in D state. Narrating the layers in order is the skill being tested.

Answer: The page cache is the kernel’s unified cache of file and block data in RAM, page-granular, serving reads and absorbing writes. Historically Linux kept a separate buffer cache for raw block metadata and folded it into the page cache long ago, so the modern answer treats them as one. Consequences worth reciting: free -h buff/cache is reclaimable, repeated file reads get memory speed, and dirty pages in cache are writes the disk has not seen yet, which is exactly the risk fsync exists to close, and connecting those dots is what operating system interview questions on caching reward.

Answer: Write-through pushes every write to the device as it happens: simple and safe, slower. Write-back acknowledges in cache and flushes later: fast, with exposure until flush. Linux is write-back, and dirty pages tracked in /proc/meminfo as Dirty are writes the application believes completed that the disk has not. Tunables like vm.dirty_ratio cap how much may sit dirty before writers are forced to flush, and unflushed dirty pages are precisely what vanishes in a power cut, tying this answer to journaling questions downstream.

Answer: Before modifying metadata, the filesystem writes intentions to a journal area; after a crash it replays that log to a consistent point instead of reconstructing state with fsck. The guarantee is filesystem integrity, not application durability: your filesystem will mount, but a transaction the app never fsynced may still be absent. That distinction, consistency versus durability, is the single most misunderstood point in operating system interview questions about journaling, and stating it verbatim earns the follow-up question’s respect.

Answer: Journal metadata only by default, the balanced choice; data=ordered, the historical default that flushes data before metadata commits, avoiding garbage-filled files; and data=journal, journaling data too, safest and slowest. Configured via mount options or tune2fs. The practical reading: in ordered or writeback modes, a crash can leave recently written files with correct metadata but stale or empty contents, which is the exact symptom that distinguishes journaling questions from durability questions in interviews.

Answer: XFS for large files, high concurrency, and big filesystems: it scales allocation and parallelism extremely well and is the RHEL default, but it cannot shrink. ext4 for general-purpose servers, smaller volumes, and when shrink might ever be needed, with decades of tooling behind it. Both journal metadata and are crash-safe. Adding that the deciding question is usually workload shape, many small files versus a few huge ones, plus one resize constraint, is the complete shape for operating system interview questions on this comparison.

Answer: The virtual filesystem is the kernel layer presenting one set of file operations, open, read, stat, to every filesystem implementation, disk-based or network. It maintains the shared objects: inodes, dentries with a cache for name lookups, and per-process file descriptions. Everything surprising about Unix file behavior traces to it: one file visible under two mounts, name lookups served from dcache, and stat on NFS behaving differently. VFS is why everything is a file is an engineering decision, not a slogan, which is the sentence operating system interview questions want here.

Answer: Pipes for simple one-way streams between related processes; unix sockets for bidirectional local client-server with permissions; TCP when it might cross a host; shared memory for the highest-throughput exchange, since data is never copied through the kernel, at the price of needing your own synchronization; signals for events, not data; and message queues for persistent priority-ordered messages. The selection rule interviewers want: pick by topology and throughput, then pay for synchronization where you chose sharing.

Answer: The kernel maps the same physical frames into multiple address spaces, via POSIX shm_open plus mmap or System V shmget, so a write by one process is immediately visible to the others with zero copies and zero syscalls in the data path. That speed is why it underpins databases, Python multiprocessing, and GPU driver transports. The bill comes due in synchronization: nothing serializes access for you, so shared memory without thoughtfully placed locks or atomics is just a race condition with better throughput.

Answer: Zero-copy removes CPU copies from a data path: classic file serving copied disk to page cache, cache to user buffer, buffer back to a socket buffer, four moves and two context switches per chunk. sendfile tells the kernel to move file pages straight to the socket, and with scatter-gather DMA only descriptors travel through the CPU. Nginx, Kafka, and Java’s transferTo all sit on it. Saying the bytes never visit userland and naming one system that exploits it is the crisp version of this classic in operating system interview questions.

Answer: fsync forces the file’s dirty pages and its metadata out to stable storage and returns only once the device acknowledges; fdatasync skips metadata unless size changed, so it is cheaper for appending workloads. This is the only line between write returned and write survived power loss, which is why databases call it per commit and why VM disks on cached storage get blamed for lost transactions. The honest caveat: it is slow by design, and grouping writes to amortize fsyncs is the standard engineering response.

Answer: Kernel threads are scheduled entities the kernel knows about, each getting its own timeslice and blocking independently: Linux maps every pthread to a kernel task, the 1:1 model, which is why ps -Lf shows them. User threads, M:N or N:1 models like green threads and goroutine runtimes, are scheduled by a library on top of fewer kernel tasks, making creation and switching almost free but risking one blocking syscall stalling many. Modern runtimes wrap or pool syscalls to fake asynchrony, and knowing that workaround is the senior flourish operating system interview questions on runtimes look for.

Answer: Non-uniform memory access: a multi-socket box has per-socket memory controllers, and a core accessing memory attached to the other socket pays remote latency, often half the bandwidth or worse. The kernel tries node-local allocation, and tools expose it: numactl --hardware, numastat, IRQ affinity via /proc/irq. The interview-relevant symptom: throughput that plateaus on a big box because memory and interrupts live on a different node from the CPU handling them. Pinning by policy is the fix, and naming that symptom is the strong answer.

Answer: Confirm the funnel first: vmstat 1 for sustained si/so, free -h for near-zero available, sar -B for pgscan climbing, which proves reclaim is starving. Find the working set: ps aux --sort=-rss | head, then stop or throttle the biggest resident, the fastest lever you have, and expect latency to recover within a minute. Only then decide structural fixes: more RAM, a cgroup memory cap on the offender, or a fix for the leak or misconfigured cache that overcommitted the box. The rule that scores: thrashing is a working-set problem, so the diagnosis must identify whose working set exceeded RAM, not just that swap moved.

Answer: A page-fault storm: the working set is being read back from disk continuously, so the system re-faults the same regions instead of progressing. Check who: per-process fault deltas with pidstat -r 1, and what for: if pgscan is high, reclaim is evicting pages the app immediately needs again, the working-set-too-small signature; if pgscan is quiet, the app itself streams cold data, like a database with a shrunken cache. Remedies follow the finding: add RAM or shrink competing caches for the first, fix the workload’s read pattern for the second. Naming both variants is what scenario operating system interview questions like this one test.

Answer: Confirm frozen state before blaming code: thread stacks via eu-stack -p PID or gdb -p batch mode, Java with jstack, and look for multiple threads parked on the same two locks with owners themselves blocked, the wait-for cycle made visible. Corroborate with pidstat -wt 1: near-zero voluntary context switches means nobody is releasing. Recovery is a restart, but capture stacks first because that evidence is the bug report. Prevention to state out loud: global lock ordering and lock timeouts turn a hang into an error, and saying which engineering ticket that becomes is the senior close.

Answer: none for fast NVMe: the device has deep internal queues and reordering that beat any kernel heuristic, and the old merging work is largely moot on flash. mq-deadline for SATA SSDs and for hypervisor or RAID volumes, where it caps worst-case latency without pretending to know geometry. bfq only where interactive fairness on slow spinning disks matters, since it costs CPU. Check and set via /sys/block//queue/scheduler, persist with udev rules. The reasoning interviewers want: schedulers exist to hide mechanical seek costs, so as seek cost vanishes, so should the scheduler.

Answer: The rebuild reads every surviving disk to recompute parity and data, so expect background I/O saturation, doubled latency on the array, and elevated stress on old drives, which is when marginal disks die and take the array with them, the risk story every RAID entry in operating system interview questions wants. Throttle the rebuild with mdadm’s sync_speed_max if the workload is latency-sensitive, but not so far that a second failure strands you. Watch progress in /proc/mdstat and error counts in mdadm --detail. The judgment call to verbalize: rebuild at full speed when the array is your only copy, throttle when the application SLA is breathing down your neck.

Answer: On Linux, load counts uninterruptible D-state tasks too, so high load with idle CPU almost always means storage or NFS waits, not compute. Confirm: ps axo state,pid,cmd | grep "^D" for a D-state pile, iostat -x 1 for await and utilization on the culprit device, and cat /proc/PID/stack on a stuck PID to see the kernel wait. Then fix the path: a hung NFS server, a saturated RAID volume, or a failing disk showing errors in dmesg. Saying load is the queue length, and the queue is in the block layer is the sentence this question exists for.

Answer: Suspect fragmentation or overcommit policy, not shortage. Check /proc/buddyinfo: plenty of order-0 pages but empty high-order columns means the kernel cannot satisfy contiguous multi-page allocations even with free memory, common after weeks of mixed-size churn or on long-forgotten huge page reserves. Check vm.overcommit_memory: mode 2 enforces commit limits that look arbitrary compared to free. Confirm the failing order with the app’s logs, then plan the honest fixes: restart or consolidate on the next window, enable compaction, or restructure the allocator’s request sizes. Reading buddyinfo out loud is the credibility move this entry in operating system interview questions is fishing for.

Answer: Correlate, do not guess: what cron or timers fire at 02:00, then what the stall looks like. If vmstat 1 shows bi/bo spikes with rising %wa, it is a batch job saturating I/O, and the fix is ionice -c3 plus cgroup io.max limits. If si/so spike, the job’s memory burst evicts hot pages, fix with a cgroup memory limit. If load spikes with runnable tasks, nice and cpuset pinning apply. Each signature maps to one lever, and articulating that mapping, symptom to knob, is exactly what scenario operating system interview questions reward.

Answer: Steal time is the hypervisor running someone else’s vCPU instead of yours: the guest wanted the CPU and the host gave it away, so no guest-side tuning recovers it. Confirm it is sustained rather than transient in mpstat -P ALL 1, check whether noisy neighbors correlate, then escalate to the platform owner: migrate to a less-contended host, reserve capacity, or change instance size. The trap this question sets: teams burn days tuning guest schedulers for a problem that exists one layer up, and naming that layer boundary is the entire answer.

Answer: Returned success is not survived the power cut. If the app writes without fsync, its data sat in the kernel’s dirty page cache and died with the cache; if it fsyncs files but the storage array has write-back cache without a battery or flush passthrough, the array lied about durability. Walk the stack in order: does the app fsync per commit, does the filesystem journal mode cover the data, does the device honor flushes, check the VM’s disk cache mode and the RAID controller’s BBU state. Pinpointing which layer skipped the flush is the diagnosis; blaming journaling first is the common wrong turn.

Answer: Never fsck a mounted or possibly-write-cached volume on running hardware. Attach the disk read-only first, ro at the VM or by policy, then run the filesystem’s own recovery: fsck.ext4 -p or xfs_repair -n for a dry run, real repair only after the dry run and only with the volume offline and a recent backup identified. If the journal itself is corrupt, replay it with the fs-specific tool before a full repair. Then close the root cause: dirty cache without flush protection, or failing hardware that dmesg will confirm. That order, read-only, dry run, repair, prevention, is the answer operating system interview questions of this kind score.

Answer: Load changes timing, not logic, so the deadlock existed in code and only becomes reachable when the contended path actually interleaves. Capture evidence at the moment: stacks from a stuck process with eu-stack, or a core with gcore, and identify the two locks and their owners. The code review then asks the textbook question: do these components acquire the same two resources in different orders? Fix by imposing a global acquisition order, or restructure to hold one lock while taking the other. Explaining why staging never reproduces it, timing, plus giving the ordering fix, answers both the engineer and the interviewer.

Answer: D state means kernel-side waits the signal system cannot touch, so killing is off the table. Identify the mount: lsof +D is expensive, so use mount plus the PIDs’ open files, or /proc/PID/stack to see the wait in the NFS or block layer. Fix the path: restore the failover target, re-export, or force-unmount a dead NFS mount with umount -f -l as the last resort; processes release when the I/O errors or completes. The scoring sentence: D states are symptoms of an I/O path problem, and every escalation of signals, including kill -9, is wasted motion until that path is repaired.

Answer: Read the kernel’s evidence first: the OOM line names the victim, its oom_score, and each task’s RSS, which is the memory audit trail the moment before death. Decide whether the kernel was right: a leak growing all week points to the app, a batch job’s burst points to scheduling policy. Mitigate by intent, not superstition: reserve headroom, set a cgroup memory limit so the offender dies alone, or pin critical daemons with negative oom_score_adj. Then schedule the real fix with the engineers. Reframing the crash as the kernel’s memory manager making a documented decision is the insight operating system interview questions about silent deaths reward.

Answer: A leak is per-process: RSS of one PID rises monotonically; confirm with ps aux --sort=-rss history and pmap -x PID showing which mappings grow, then hand the profile to the developers. Fragmentation is system-wide: total RSS stays flat but high-order allocations start failing and /proc/buddyinfo shows high-order columns drained while order-0 stays rich. The leak fix is code or a restart cadence; the fragmentation fix is compaction, restart, or reducing long-lived mixed-size churn. Naming the two different witnesses, RSS trend versus buddyinfo shape, is the whole diagnosis.

Answer: Host-wide periodic mechanisms first, because unrelated services share the kernel. Check writeback: vm.dirty_ratio and dirty_expire_centisecs flushing a big dirty burst through one slow device, visible as bo spikes in vmstat 1 and await spikes in iostat -x. Check the journald or logrotate cycle, and any 30-second monitoring scrape that triggers expensive commands. Then kernel housekeeping: reclaim and compaction cycles in /proc/vmstat deltas. The discipline being tested: before profiling the apps, exclude the periodic kernel and platform work they all share, and say so in that order.

Answer: futex time means threads are blocking on kernel synchronization, so the bottleneck is lock contention, not CPU. Quantify: perf lock or pidstat -wt 1 for voluntary context switches and perf top for the hot path. Then reduce sharing: shard the contended structure so threads touch disjoint memory, switch coarse locks to per-key or per-shard locks, move to atomics for counters, or hand work to queues with fewer, longer critical sections. Adding threads to a contended lock makes it worse, and stating that inverted expectation, more threads, more contention, is precisely what operating system interview questions on scaling measure.

Answer: The kernel is consuming most cycles on the system’s behalf: syscall-heavy code, page fault handling, reclaim, or softirq processing. Split it: mpstat -P ALL 1 to separate %sys from %soft and %irq, strace -c -p PID to count syscalls per second for the hottest process, sar -B for fault and reclaim rates, and perf top for kernel symbols, where native_queued_spin_lock or copy_user_bytes point at different culprits. Common verdicts: an app doing tiny writes instead of buffering, or churning the page cache. %sys is a pointer, not a verdict, and saying which measurement resolves the pointer is the expected move.

Answer: Not a problem, and explaining why is the test. Those pages were cold when memory was tight once; the kernel paged them out, they have not been touched since, and paging them back in proactively would waste I/O. The metrics that matter are current movement and pressure: si/so in vmstat 1, pgscan and pgsteal in sar -B, and the available column in free -h. All quiet means the box is fine. Announcing an emergency because a swap column is nonzero is the classic junior signal, and this question exists to see whether you read motion rather than position.

Answer: Test the hypothesis cheaply before touching tuning: pidstat -wt 1 for involuntary context switch rates per thread, perf sched latency for actual run delays, and compare against a pre-upgrade baseline. In parallel, check what else the upgrade changed: huge page behavior, THP settings reset to defrag, cgroup v2 controller changes, or the EEVDF transition altering latency sensitivity for tasks with equal weights. GC logs matter too, since stalls blamed on the kernel are often old collection pauses freshly visible. Ruling out the platform’s new defaults before blaming scheduling policy is the diagnostic order senior operating system interview questions reward.

Answer: Blocking reads on an unreliable path turn one slow file into many frozen threads: each enters the kernel’s NFS wait, lands in D state, and consumes a worker, so a pool of 32 dies on 32 stale reads. Confirm with ps -o state,wchan -p PID and a D-state census. Mitigations in order: mount with shorter timeo and retrans, use soft only where data loss is acceptable, isolate the dependency to a dedicated small pool or a local cache tier, and alarm on D-state counts. The architectural sentence: never let a network filesystem share a thread pool with your critical path.

Answer: Most likely dirty page writeback: the app wrote fast into the page cache, Dirty climbed toward vm.dirty_ratio, and crossing it forces the writing tasks themselves into synchronous flush mode until below dirty_background_ratio, which is the stall. Confirm: watch Dirty in grep -E 'Dirty|Writeback' /proc/meminfo and correlate its cliffs with iostat -x await spikes. Fix by shaping it: lower dirty_ratio so bursts drain earlier and smaller, move the write-heavy path to a faster device, or make the app fsync at controlled points instead of letting the kernel decide. Mapping the sawtooth to those two sysctls is the scoring detail in operating system interview questions about writeback.

Answer: Verify locality before asserting it: numactl --hardware to map nodes and CPUs, numastat -p PID for the ratio of remote to local memory hits, and perf stat -e node-loads,node-loads-misses on the hot process. Remote hits above roughly a third on a memory-hungry service explain flat scaling. The fix is placement: bind the process and its IRQs to one node with numactl --cpunodebind --membind, split the service into per-node instances, or ask the platform about NUMA-aware VM topology. Confirming with counters before re-architecting is the professional move this question screens for.

Answer: Walk every layer that can say yes and mean no: the app must fsync or use a WAL with group commit, the filesystem must be mounted so its journal covers the data path you rely on, the block device must honor flushes, check the VM cache mode, none or writeback with O_DIRECT semantics, and the RAID controller must have a working BBU with flush passthrough on failure. Test with a fault injection tool like dm-flakey or the app’s own crash harness, because vendors’ defaults lie. Naming one layer per breath, app, filesystem, guest cache, array, is the rhythm operating system interview questions on durability expect.

Answer: Both directions, with a recommendation. For: large resident sets with stable, contiguous access, databases, big JVM heaps, cut TLB misses dramatically, which direct measurement can confirm with perf stat -e dTLB-load-misses. Against: small or sparse working sets waste memory per huge page, THP’s defrag stalls create exactly the latency spikes you were paid to remove, and memory-ballooned hosts suffer. The professional position: reserve explicit huge pages for the workloads that measure a win, disable or tune THP to madvise on latency-sensitive hosts, and never ship it fleet-wide on faith. Arguing from measurement, not fashion, is the point of this scenario and of operating system interview questions that ask you to take a side.

Answer: Four commands, one pass, in this order: mpstat -P ALL 1, high %usr means CPU-bound, high %iowait redirects to storage, high %steal means the hypervisor; vmstat 1, nonzero si/so and high r queue mean memory pressure or runqueue saturation; iostat -x 1, await above a few milliseconds with high util convicts the disk; pidstat -wt 1, massive voluntary context switches with modest CPU point at lock churn. Each command eliminates a layer, and narrating the eliminations out loud, rather than diving into one tool, is the entire skill scenario operating system interview questions are built to test.