Question 1

What is the difference between a process and a thread?

Accepted Answer

A process is an independent unit of execution with its own memory space, including its own heap, stack, code segment, and data segment. The operating system allocates separate resources to each process and enforces memory isolation between them. This means one process cannot directly read or write the memory of another process, which provides strong fault isolation — if one process crashes, others remain unaffected.

A thread, by contrast, is a lightweight unit of execution that exists within a process. Multiple threads in the same process share the same memory space — they can read and write the same heap, global variables, and file descriptors. However, each thread maintains its own stack and its own set of CPU registers, including its own program counter. This means each thread has an independent execution path but operates on shared data.

The key trade-offs between the two come down to isolation versus efficiency. Process creation is expensive because the OS must allocate a new address space, set up page tables, and copy or clone resources. Context switching between processes is also costlier because the CPU must flush the TLB and swap page tables. Thread creation and context switching are cheaper because threads share the same address space — the OS only needs to save and restore registers and the stack pointer.

Communication between processes requires explicit inter-process communication mechanisms such as pipes, message queues, shared memory segments, or sockets. These add complexity and overhead. Threads communicate by simply reading and writing shared memory, which is fast but introduces the risk of race conditions. You must use synchronization primitives like mutexes, semaphores, or condition variables to coordinate thread access to shared data safely.

In practice, you choose processes when you need fault isolation — for example, a web server like Nginx uses worker processes so that a crash in one worker does not bring down the server. You choose threads when you need high-performance concurrency with shared state — for example, a database engine might use threads to handle concurrent queries that access the same in-memory buffer pool. Many modern systems use a hybrid approach: multiple processes each running multiple threads, combining isolation at the process level with efficient concurrency at the thread level.

It is also worth noting that some languages impose constraints. Python's Global Interpreter Lock means CPU-bound work does not benefit from threads in CPython, pushing developers toward multiprocessing. Languages like Java and Go have rich threading or goroutine models that make concurrent programming within a single process more natural.

Question 2

What is a race condition and how do you prevent it?

Accepted Answer

A race condition occurs when two or more threads or processes access shared data concurrently, and at least one of them modifies it, such that the final outcome depends on the non-deterministic order of execution. The result is unpredictable behavior — the program may produce correct results on some runs and incorrect results on others, making race conditions notoriously difficult to reproduce and debug.

A classic example is a bank account balance update. Suppose two threads both read a balance of $100. Thread A adds $50 and writes $150. Thread B adds $30 and writes $130. The final balance should be $180, but because both threads read the original value before either wrote, one update is lost. This is called a lost update and it is one of the most common manifestations of a race condition.

At a lower level, even a simple increment operation like counter++ is not atomic in most languages. It compiles to three separate instructions: load the value from memory, increment it, and store it back. If two threads execute these instructions interleaved, the counter may only increment once instead of twice.

There are several strategies to prevent race conditions. The most common is mutual exclusion using a mutex or lock. Before accessing shared data, a thread acquires the lock. Any other thread that tries to acquire the same lock blocks until the first thread releases it. This serializes access to the critical section.

Atomic operations are another approach. Hardware provides compare-and-swap (CAS) and other atomic instructions that complete in a single uninterruptible step. Languages expose these through constructs like Java's AtomicInteger or C++'s std::atomic. Atomics avoid the overhead of locks but only work for simple operations on single variables.

A third strategy is to avoid shared mutable state entirely. Immutable data structures, message passing between threads (as in Go's channels or Erlang's actor model), and thread-local storage all eliminate the conditions that allow races to occur. This is often the most robust approach because it removes the problem at the design level rather than patching it with synchronization.

Question 3

What are the four conditions for deadlock and how can you prevent it?

Accepted Answer

A deadlock is a situation where two or more threads are permanently blocked, each waiting for a resource held by another thread in the group. No thread can proceed because each is waiting for a resource that will never be released. For a deadlock to occur, all four of the Coffman conditions must hold simultaneously.

The first condition is mutual exclusion. At least one resource must be held in a non-sharable mode — only one thread can use it at a time.

The second condition is hold and wait. A thread must be holding at least one resource while waiting to acquire additional resources held by other threads.

The third condition is no preemption. Resources cannot be forcibly taken away from a thread. A resource can only be released voluntarily by the thread holding it.

The fourth condition is circular wait. There must exist a circular chain of threads, where each thread holds a resource that the next thread in the chain is waiting for.

All four conditions must hold simultaneously. If you can break even one, deadlock becomes impossible.

The most practical prevention strategy is breaking the circular wait condition by imposing a total ordering on resource acquisition. Assign every lock a numeric priority and require that all threads acquire locks in increasing order. If Thread A holds Lock 1 and needs Lock 2, it can acquire it. But if it holds Lock 2 and needs Lock 1, the ordering rule prevents it from requesting Lock 1 without first releasing Lock 2. This eliminates cycles in the wait graph.

To break hold and wait, you can require threads to request all needed resources atomically before beginning execution. If any resource is unavailable, the thread releases everything and retries.

To break no preemption, you can allow the system to forcibly revoke resources. If a thread cannot acquire a needed resource, it releases all currently held resources and retries later.

Beyond prevention, there is deadlock detection and recovery. Systems like databases often use a wait-for graph and periodically check for cycles. When a cycle is found, one transaction is aborted (the victim) to break the deadlock.

Question 4

What does thread safety mean? Is Python's dict thread-safe?

Accepted Answer

Thread safety means that a data structure or piece of code produces correct results when accessed concurrently by multiple threads, without requiring the caller to perform external synchronization. A thread-safe operation is one where concurrent invocations cannot interleave in a way that corrupts state or produces incorrect output.

Python's dict has a nuanced safety story tied to the Global Interpreter Lock (GIL). The GIL ensures that only one thread executes Python bytecode at a time, which means individual dict operations like __getitem__, __setitem__, and __delitem__ are atomic at the bytecode level. You will not get a segfault or a corrupted internal structure from concurrent reads and writes. In that narrow sense, built-in dict operations are GIL-protected.

However, GIL-atomicity does not mean thread-safe for compound operations. Consider d[key] += 1: this compiles to a LOAD, ADD, STORE sequence -- three bytecode instructions. The GIL can be released between any of these, so two threads can both read the old value, both increment it, and both write back the same incremented value, losing one update. This is a classic lost-update race condition.

Additionally, iterating over a dict while another thread modifies it will raise a RuntimeError: dictionary changed size during iteration. Python intentionally detects this rather than silently producing wrong results.

For truly thread-safe dict operations, you have several options. threading.Lock or threading.RLock can guard compound operations. The collections module does not provide a thread-safe dict directly, but queue.Queue is thread-safe for producer-consumer patterns. In Python 3.7+ you can also use concurrent.futures or high-level abstractions that avoid shared mutable state entirely.

The takeaway for interviews: dict is safe from corruption at the interpreter level due to the GIL, but it is not thread-safe for compound operations or iteration under concurrent modification. Never rely on GIL-atomicity as a substitute for explicit synchronization when correctness depends on multi-step operations.

Question 5

How does a hash map work internally?

Accepted Answer

A HashMap is a data structure that stores key-value pairs and provides O(1) average-case lookup, insertion, and deletion. It achieves this by using a hash function to convert keys into array indices.

When you insert a key-value pair, the HashMap first computes the hash code of the key — an integer that represents the key. It then maps this hash code to a bucket index, typically using modular arithmetic: index = hash(key) % array_length. The value is then stored at that index in the underlying array.

The critical challenge is collision handling — what happens when two different keys hash to the same bucket index. There are two primary strategies.

Chaining stores a linked list (or another collection) at each bucket. When a collision occurs, the new entry is appended to the list. To look up a key, the HashMap hashes it to find the bucket, then traverses the list comparing keys using equals(). Java's HashMap uses chaining, and since Java 8, converts the linked list to a red-black tree when a single bucket exceeds 8 entries, improving worst-case from O(n) to O(log n).

Open addressing stores all entries directly in the array. When a collision occurs, the HashMap probes for the next available slot. Linear probing checks slots sequentially. Python's dict uses open addressing. The advantage is better cache locality; the disadvantage is more complex deletion (requires tombstone markers).

The load factor is the ratio of stored entries to total buckets (n / capacity). Most implementations define a threshold — commonly 0.75 — and when exceeded, the HashMap rehashes: allocating a new array (typically double the size) and reinserting every entry. This is O(n) but happens infrequently enough that insertions remain O(1) amortized.

For a HashMap to work correctly, keys must satisfy two contracts: the hash function must be deterministic, and if two keys are equal (via equals()), they must have the same hash code. Violating this contract causes the HashMap to lose entries or return incorrect values.

Question 6

What is a hash collision and how do chaining and open addressing handle it?

Accepted Answer

A hash collision occurs when two distinct keys produce the same hash value modulo the table size, and therefore map to the same bucket. Because hash functions compress a large key space into a small fixed-size array, collisions are inevitable -- by the birthday paradox, they become likely well before the table is full.

Chaining (separate chaining) resolves collisions by allowing each bucket to hold multiple entries. Each bucket is the head of a linked list (or in modern implementations, a dynamic array or tree). When two keys hash to the same bucket, both are appended to that bucket's list. Lookup requires computing the hash, jumping to the bucket, then linearly scanning the list for the matching key. Average-case time complexity is O(1) when load factor is low. Worst case -- all keys in one bucket -- degrades to O(n). Java's HashMap uses chaining and switches each bucket's list to a red-black tree when the bucket exceeds 8 entries, keeping worst-case lookup at O(log n).

Open addressing resolves collisions by finding a different slot within the same array. When a collision occurs, the algorithm probes a sequence of slots until it finds an empty one. The three main probe strategies are: linear probing (check next slot), quadratic probing (jump by i-squared positions), and double hashing (use a second hash function to determine jump size). Open addressing avoids the overhead of pointer-chasing and is more cache-friendly because all data stays in a contiguous array. However, it is sensitive to load factor -- performance degrades rapidly above 70-80% occupancy. Deletions are also more complex: you cannot simply mark a slot empty or you will break probe chains; you must use a tombstone marker. Python's dict uses open addressing with a compact table and pseudo-random probing derived from the key's hash.

Question 7

What are the four pillars of object-oriented programming?

Accepted Answer

The four pillars of object-oriented programming -- encapsulation, abstraction, inheritance, and polymorphism -- describe the core mechanisms by which OOP manages complexity in large codebases.

Encapsulation is the bundling of data and the methods that operate on that data within a single unit (the class), along with restricting direct external access to the internal state. In practice this means using access modifiers (private, protected, public) to expose only a controlled interface. The benefit is that you can change internal implementation details without breaking callers. A BankAccount class exposes deposit() and withdraw() but keeps the balance field private, preventing external code from setting a negative balance directly.

Abstraction means hiding implementation complexity behind a simplified interface. Users interact with what an object does, not how it does it. An interface or abstract class defines the contract; concrete implementations provide the detail. A Shape abstract class defines area() without specifying the formula -- callers do not need to know whether the shape is a circle or rectangle.

Inheritance allows a class to derive from another class, reusing and extending its behavior. A subclass inherits fields and methods from a superclass and can override or extend them. Dog and Cat classes can inherit from Animal, reusing the name field and eat() method while providing their own sound() implementations. Inheritance models is-a relationships and reduces duplication, but deep hierarchies can become brittle -- prefer composition when in doubt.

Polymorphism (from Greek: many forms) allows objects of different types to be treated uniformly through a common interface. There are two main forms: subtype polymorphism (runtime dispatch -- a variable of type Animal can hold a Dog or Cat; calling sound() invokes the correct override) and parametric polymorphism (generics/templates -- code written once works for any type). Polymorphism decouples callers from concrete types, making systems extensible without modifying existing code.

These four pillars work together: encapsulation protects internal state, abstraction hides complexity, inheritance reuses behavior, and polymorphism enables flexible behavior dispatch. Together they enable code that is modular, testable, and open for extension without requiring modification of existing logic.

Question 8

Explain all five SOLID principles with examples.

Accepted Answer

SOLID is an acronym for five object-oriented design principles introduced by Robert Martin. Each targets a different source of design fragility.

Single Responsibility Principle (SRP): a class should have only one reason to change. If a class handles both business logic and persistence, a change in the database schema forces a change to the business logic class. Split them: one class models the domain, another handles storage. SRP reduces coupling and makes classes easier to test.

Open/Closed Principle (OCP): software entities should be open for extension but closed for modification. Instead of adding if/else branches to an existing class when requirements grow, you extend behavior through new subclasses or strategy objects. A PaymentProcessor that switches on payment type violates OCP; extracting a PaymentStrategy interface and injecting implementations satisfies it.

Liskov Substitution Principle (LSP): subtypes must be substitutable for their base types without altering program correctness. If Square extends Rectangle and overrides setWidth() to also set height (to keep it square), code that relies on Rectangle's behavior -- setting width and height independently -- breaks silently. The fix is often to not use inheritance where the subtype cannot honor the contract of the supertype.

Interface Segregation Principle (ISP): clients should not be forced to depend on interfaces they do not use. A fat interface that includes methods irrelevant to most implementors forces implementors to provide no-op stubs. Split large interfaces into smaller, focused ones. A Worker interface with work() and eat() is problematic for robots that do not eat -- split into Workable and Feedable.

Dependency Inversion Principle (DIP): high-level modules should not depend on low-level modules; both should depend on abstractions. A service class that directly instantiates a DatabaseRepository cannot be tested without a real database. Inject an abstract Repository interface instead -- the service depends on the abstraction, and the concrete implementation is wired in at the composition root. This is the foundation of dependency injection.

Applied together, SOLID principles produce code where each class has a clear purpose, extension points are explicit, contracts are honored, interfaces are minimal, and dependencies flow toward abstractions.

Question 9

Explain BFS and DFS — when would you use each?

Accepted Answer

Breadth-First Search (BFS) and Depth-First Search (DFS) are the two fundamental graph traversal algorithms. Understanding when to use each requires knowing what each optimizes for.

BFS explores the graph level by level. It starts at a source node and visits all neighbors before moving to neighbors-of-neighbors. Internally it uses a queue (FIFO). Because it visits nodes in order of increasing distance from the source, BFS guarantees it finds the shortest path (in terms of edge count) in unweighted graphs. Time complexity is O(V + E) where V is vertices and E is edges. Space complexity is O(V) in the worst case, since you may hold an entire level of the graph in the queue simultaneously.

BFS is the right choice when: you need the shortest path in an unweighted graph or grid; you need to find all nodes within k hops of a source; you are doing level-order tree traversal; or you are solving problems where the optimal solution is the closest one.

DFS explores as far as possible along a path before backtracking. It uses a stack -- either an explicit one or the call stack via recursion. DFS does not guarantee a shortest path. Time complexity is also O(V + E). Space complexity is O(V) in the worst case for the recursion stack, but typically proportional to the depth of the deepest path.

DFS is the right choice when: you need to detect a path between two nodes (not necessarily shortest); you are detecting cycles; you need topological sort (DFS post-order on a DAG); you are exploring all solutions or permutations (backtracking); or you need to compute strongly connected components.

A key practical distinction: BFS can be infeasible on very deep or infinite graphs because the queue grows wide; DFS may hit recursion depth limits on very deep graphs. In interview problems, BFS is almost always the answer to minimum-steps questions; DFS is almost always the answer to does-a-path-exist or enumerate-all-solutions questions.

Question 10

What is the difference between primitive and reference types? How do stack and heap relate?

Accepted Answer

The distinction between primitive and reference types is fundamental to understanding how languages manage memory and pass values between functions.

Primitive types (int, float, bool, char) store their actual value directly in the memory allocated for the variable. They have a fixed, known size. When you assign a primitive to another variable or pass it to a function, the value is copied. Changing the copy does not affect the original.

Reference types (objects, arrays, most data structures) store a reference -- a pointer or memory address -- rather than the data itself. The variable holds the address of the object, which lives on the heap. When you assign a reference type to another variable, you copy the reference, not the object. Both variables now point to the same object -- changes through one are visible through the other.

The stack is a region of memory organized as a LIFO structure. Each function call gets a stack frame that holds local variables, return addresses, and function arguments. Allocating on the stack is extremely fast -- it is just moving a stack pointer. Stack memory is automatically reclaimed when the function returns. Stack size is limited (typically 1-8MB per thread), so large allocations or deep recursion can cause a stack overflow.

The heap is a larger, dynamically managed memory region where objects live for arbitrary lifetimes -- beyond the function call that created them. Allocating on the heap is slower because the memory allocator must find a suitable free region, update bookkeeping, and potentially handle fragmentation. Heap memory is managed either by the programmer (C/C++ malloc/free), a garbage collector (Java, Python, Go), or a reference counting system (Python, Swift).

In Java, all primitive types are stack-allocated when declared as local variables; all objects are heap-allocated. In Python, everything is an object on the heap -- even integers are objects, though CPython caches small integer objects. In C and C++, you control allocation explicitly.

The key insight: primitives are copied by value, references are copied by reference, and the stack/heap distinction governs lifetime and allocation cost.

Question 11

What is the difference between a mutex and a semaphore?

Accepted Answer

A mutex (mutual exclusion lock) and a semaphore are both synchronization primitives, but they model different problems and have different ownership semantics.

A mutex is a binary lock that allows exactly one thread to hold it at a time. Its defining characteristic is ownership: only the thread that acquired the mutex can release it. This models the exclusive access pattern — one critical section, one thread. If thread A holds a mutex and thread B tries to acquire it, thread B blocks until thread A releases it. Mutexes are used to protect shared data structures, file handles, or any resource that can't be safely accessed concurrently.

A semaphore is a counter-based primitive initialized to N. Each `acquire()` decrements the counter; each `release()` increments it. When the counter reaches 0, further `acquire()` calls block. Critically, semaphores have no ownership: any thread can call `release()`, even one that never called `acquire()`. A binary semaphore (N=1) looks like a mutex but lacks ownership enforcement — this is a meaningful difference.

Counting semaphores model limited resource pools: N database connections, N worker slots, N permits to rate-limit throughput. A thread acquires a semaphore to take a slot and releases it when done. Python's `threading.Semaphore(n)` and `asyncio.Semaphore(n)` implement this directly.

A signaling semaphore (initialized to 0) is used for thread coordination: one thread calls `acquire()` (and blocks), another calls `release()` to signal that an event has occurred. This is fundamentally different from mutual exclusion — it's about ordering, not exclusive access.

The ownership distinction has safety implications. A mutex with ownership allows deadlock detection (the OS or runtime knows which thread holds which mutex) and enables priority inheritance (elevating a low-priority thread holding a needed mutex). A semaphore cannot support these because any thread can release it.

In Python's asyncio, `asyncio.Lock()` is the coroutine-safe mutex equivalent and `asyncio.Semaphore(n)` is the counting primitive. In the threading module, `threading.Lock()` and `threading.Semaphore()` are the synchronous counterparts.

Question 12

What is virtual memory and how do paging and swap work?

Accepted Answer

Virtual memory is an abstraction that gives each process its own private address space, isolated from other processes and from the physical memory layout. A process sees a contiguous address space starting at 0 (in most architectures), regardless of how physical memory is actually arranged or shared.

Paging implements virtual memory by dividing both virtual and physical memory into fixed-size chunks: virtual pages and physical frames (typically 4KB on x86-64, though huge pages of 2MB or 1GB exist). The CPU's Memory Management Unit (MMU) translates every virtual address to a physical address on each memory access using a page table — a per-process data structure maintained by the OS. The translation uses the top bits of the virtual address as the page number to look up the frame number, then adds the offset within the page.

Page table lookups would be too slow on every memory access, so the MMU includes a Translation Lookaside Buffer (TLB) — a hardware cache of recent virtual-to-physical translations. A TLB hit resolves in ~1 cycle; a TLB miss requires a page table walk (several memory accesses). When the OS switches processes, TLB entries must be flushed or tagged with address space identifiers (ASIDs).

When a process accesses a page that isn't currently mapped to a physical frame — because it was never loaded, or has been evicted — the MMU triggers a page fault. The OS page fault handler either loads the page from disk (demand paging), allocates a new zero-filled page, or handles copy-on-write (fork creates child processes that share parent pages until either writes).

Swap (swap space or page file) extends physical memory to disk. When physical RAM is exhausted, the OS's page replacement algorithm (LRU approximations like clock/second-chance in Linux) selects victim pages to evict to swap. Future accesses page them back in. Swap allows overcommitting memory but at a severe latency cost — disk access is 100,000x+ slower than RAM. Modern production systems often run without swap (Kubernetes pods, high-performance servers) to avoid latency spikes from swap thrashing.

Memory-mapped files use the same paging mechanism: file regions are mapped into the virtual address space and pages are loaded on demand from the file, not RAM. This is how executables are loaded and how databases like SQLite and PostgreSQL read their files efficiently.

Question 13

What is the difference between concurrency and parallelism?

Accepted Answer

Concurrency and parallelism are related but distinct concepts that are frequently conflated, even by experienced engineers.

**Concurrency** is a program structure: the ability to handle multiple tasks that are in progress simultaneously by interleaving their execution. Concurrent tasks don't need to run at the exact same instant—they can share a single CPU through context switching. The key insight is that concurrency is about *dealing with* multiple things at once, not *doing* them simultaneously. A single-core processor can run concurrent code by switching between tasks rapidly. Concurrency is primarily a solution to latency: while one task is waiting (for I/O, a lock, a network response), another can make progress.

**Parallelism** is a runtime property: multiple tasks are executing at the exact same moment on multiple physical cores or processors. Parallelism requires hardware support—multiple CPUs or cores. It's primarily a solution to throughput and CPU-bound performance: you want to do more computation per unit time by splitting work across cores.

The classic illustration from Rob Pike (Go designer): concurrency is juggling—you can only hold one ball at a time but keep multiple in the air by switching. Parallelism is having multiple jugglers, each handling their own balls simultaneously.

In practice: Python's `asyncio` is concurrent but not parallel—tasks interleave on one thread, yielding at `await` points. Python's `multiprocessing` is parallel—separate OS processes each have a core. Python's `threading` is concurrent (and, due to the GIL, rarely parallel for CPU-bound work).

A concurrent design is a prerequisite for parallelism on shared-memory systems—you must structure code to decompose work before you can run it in parallel. But concurrent code can run on a single core, while parallel execution always requires multiple.

The practical interview point: for I/O-bound workloads (web servers, database clients), concurrency alone (async I/O or threading) is sufficient and often more efficient than parallelism. For CPU-bound workloads (image processing, ML inference, data transforms), you need true parallelism via multiple processes or cores.

Question 14

What is the difference between method overriding and method overloading?

Accepted Answer

Method overriding and method overloading are both forms of polymorphism but operate at different points in the execution lifecycle and serve distinct purposes.

**Method overriding** occurs in inheritance hierarchies. A subclass provides its own implementation of a method that is already defined in a parent class, using the same name, same parameters, and same return type. At runtime, when the method is called on an object, the actual runtime type of the object determines which implementation executes—this is dynamic dispatch (or late binding). Overriding is the mechanism behind polymorphism: you can write code against a base class interface and have subclass behavior execute transparently.

In Python, overriding is implicit—just define a method with the same name in a subclass. In Java/C#, methods are overridable by default (Java) or must be marked `virtual`/`override`. The `super()` call allows invoking the parent's implementation within the override.

**Method overloading** allows defining multiple methods with the same name but different parameter signatures (number or types of parameters). The compiler (in statically typed languages like Java) selects the correct method to call at compile time based on the argument types—this is static dispatch (or early binding). Overloading is a compile-time feature.

Python does not natively support method overloading in the traditional sense—the last definition of a function name wins. Overloading is simulated using default arguments, `*args`/`**kwargs`, or `functools.singledispatch` for type-based dispatch.

The key distinctions: overriding is runtime, inheritance-based, and achieves subtype polymorphism. Overloading is compile-time (or statically dispatched), signature-based, and achieves ad-hoc polymorphism. Overriding requires a parent-child class relationship; overloading does not.

A common interview clarification: Python's `__dunder__` methods (like `__add__`, `__str__`) are a form of operator overloading—different from overriding in that they're invoked by operators/builtins rather than direct calls.

Question 15

What is a context switch and why is it expensive?

Accepted Answer

A context switch is the mechanism by which the operating system's scheduler pauses one executing process or thread and resumes another. It is fundamental to multitasking—the OS creates the illusion of simultaneous execution by rapidly switching between tasks.

**What happens during a context switch**: The CPU state of the outgoing task must be fully saved to its Process Control Block (PCB) or Thread Control Block (TCB): all general-purpose registers, the program counter (where execution was), the stack pointer, CPU flags, and floating-point/SIMD register state. The scheduler then selects the next task, loads its saved state into the CPU registers, and resumes execution from where that task left off.

**Why context switches are expensive**: The register save/restore itself takes ~hundreds of nanoseconds and is relatively cheap. The real costs are indirect:

1. **TLB flush**: Each process has its own virtual-to-physical address mapping. Switching processes invalidates the TLB (Translation Lookaside Buffer), causing subsequent memory accesses to take slower page-table walks until the TLB warms up again. Thread context switches within the same process don't require a TLB flush (shared address space).

2. **CPU cache cold**: The outgoing task's working set was in L1/L2 cache. The new task's data is likely not. The first many memory accesses after a switch are cache misses, taking 100× longer than cache hits. This is the dominant cost for cache-sensitive workloads.

3. **Pipeline flush**: Modern CPUs use deep out-of-order execution pipelines. A context switch requires flushing the pipeline, discarding speculative work.

4. **Scheduler overhead**: The OS scheduler itself runs, selecting the next task from run queues—additional CPU cycles not doing user work.

Thread context switches are cheaper than process switches (no TLB flush, shared memory mappings), and user-space context switches (green threads, coroutines) are cheaper still—they only save/restore a minimal software stack frame, with no kernel involvement.

This cost is why high-performance servers prefer event-driven async models (asyncio, Node.js) over thread-per-request models: thousands of coroutines can multiplex on one thread with no context-switch overhead.

Question 16

What is a file descriptor?

Accepted Answer

A file descriptor (FD) is a small non-negative integer that the operating system kernel uses to represent an open I/O resource within a process. When a process opens a file, creates a socket, or establishes a pipe, the kernel returns an FD — typically the smallest available integer starting from 0. The process then uses this integer in subsequent system calls (`read`, `write`, `close`, `select`, `epoll_ctl`) to refer to that resource without needing to know its underlying type.

Every process starts with three FDs open by convention: 0 (stdin), 1 (stdout), and 2 (stderr). These are just entries in the process's file descriptor table like any other.

Under the hood, the kernel maintains a per-process **file descriptor table** — an array where each index (the FD) points to an entry in a system-wide **open file table**. The open file table entry stores the file offset (current read/write position), access mode (read/write/append), and a pointer to the underlying **vnode** (inode reference). Multiple FDs, potentially from different processes, can point to the same open file table entry — this happens after `fork()`, where parent and child share file offsets.

The UNIX design philosophy of "everything is a file" means FDs abstract over: regular files, directories, character and block devices, named and anonymous pipes (FIFOs), sockets (TCP, UDP, Unix domain), terminal devices (TTYs), and special files like `/dev/null` and `/dev/random`. Calling `read()` on a socket, a pipe, or a file uses the same syscall — the kernel dispatches to the correct implementation via the vnode's operation table.

FDs are process-local. The same integer in two different processes refers to different resources. FDs are inherited across `fork()` (unless marked `O_CLOEXEC`) and can be passed between processes via Unix domain sockets using `sendmsg` with `SCM_RIGHTS`.

Operating systems impose limits on open FDs: `ulimit -n` shows the per-process soft limit (often 1024 or 65536). Servers handling many concurrent connections must raise this limit. Leaking FDs — opening resources without closing them — exhausts the table and causes `EMFILE` errors, a common production bug.

CS Fundamentals Interview Questions — What Senior Engineers Need to Know

All 16 Questions

How to Prepare

Related Topics

Test Your Knowledge