Operating Systems

About these operating systems questions

This is a practice topic, not a vendor exam. The questions cover the operating system concepts that come up in software engineering and systems interviews, and that sit underneath much of cloud and container work: processes and threads, scheduling, memory, concurrency and file systems. They suit computer science students revising for an exam or interview, backend developers who want to understand why their program slows down or deadlocks, and anyone heading into Linux, Kubernetes or performance work.

The questions follow the structure of the free textbook Operating Systems: Three Easy Pieces, which groups the subject into virtualisation, concurrency and persistence. Most are small scenarios rather than definitions: two threads update a counter, a machine starts thrashing, or a crash happens halfway through a file write, and you decide what happens and why.

What the questions cover

There is one 10-question test so far. It covers:

• Processes and threads. What threads in one process share and what each keeps to itself.
• CPU scheduling. How the time slice length trades response time against context-switch overhead in round robin, and how a multi-level feedback queue uses a periodic priority boost to stop long jobs starving.
• Kernel mode and system calls. How a system call traps into the kernel and why user code can't simply jump there.
• Concurrency and synchronisation. Why an unprotected shared counter loses updates, and how a counting semaphore limits access to a pool of resources.
• Deadlock. How two locks taken in different orders deadlock, and why a global lock order prevents it.
• Virtual memory. What thrashing is and how it relates to working sets that no longer fit in memory.
• Caching and locality. Why the order you traverse a large array changes its speed.
• File systems. How journaling lets a file system recover consistently after a crash.

How to use them

• Draw it out. Interleave two threads step by step on paper, or sketch the pages each process is touching, before choosing an answer.
• Ask what resource is involved in each question: the CPU, memory, a lock or the disk. That usually tells you which mechanism the question is really about.
• Write small programs to see the effects. A threaded counter without a lock, or a nested loop over a big array in row and column order, shows the behaviour in a few lines.
• Read the matching chapter of the textbook for any question you miss. The chapters are short, free and written for exactly these topics.
• In interviews, explain trade-offs, not just names. Saying why a shorter time slice helps interactive jobs but costs throughput is worth more than naming the algorithm.

These questions are original, written from Operating Systems: Three Easy Pieces and other public references. They are not taken from any exam or interview question bank.