Tell me how you'd decide between threads and processes for a CPU-heavy component, and what the OS-level costs of that choice actually are.

technical-conceptual · Senior level · software-engineering

What the interviewer is really asking

Assesses understanding of the OS process/thread model — shared versus isolated address spaces, context-switch and scheduling cost, fault isolation, and IPC overhead — and the judgment to pick based on the workload rather than a default.

What to say

• Distinguish the models concretely: threads share one address space so communication is cheap (shared memory) but a crash or memory corruption takes the whole process down; processes have isolated address spaces giving fault isolation and security boundaries at the cost of IPC and heavier context switches that flush more state.
• Tie the decision to the workload: CPU-bound work that fans out and rejoins favors threads or a thread pool for cheap shared state, while untrusted or crash-prone work favors process isolation so one failure can't corrupt the rest.
• Mention that in a runtime with a global interpreter lock you may need processes for true CPU parallelism regardless, and that you'd measure context-switch rate and scheduling latency before assuming threads are free.

What to avoid

• Saying threads are always lighter and better without acknowledging the loss of fault isolation and the shared-state hazards.
• Ignoring the runtime — recommending threads for CPU parallelism in an interpreter that serializes execution under a global lock.
• Treating context switches as free; not mentioning the cost of TLB and cache effects when switching between isolated address spaces.

Example answers

Strong: For CPU-heavy fan-out where the pieces trust each other, I'd use a bounded thread pool sized near the core count so shared state is cheap and I avoid IPC. If a piece runs untrusted code or crashes the process, I'd isolate it in a separate process for fault containment even though that adds IPC cost. And if the runtime has a global lock, threads won't give real CPU parallelism, so I'd reach for processes there regardless.

Weak: Threads are lighter than processes and avoid the overhead of spawning, so I'd just use a big thread pool — that's the standard answer for performance.