22 topics · interview-ready · Linux-flavoured
Operating systems, as a set of solved problems
An OS is a pile of clever answers to one question: how do you let many untrusting programs share one machine without any of them noticing, lying, or bringing it down? Every topic here is one of those answers, with the cost attached.
How to study OS
OS is the subject people revise the most and understand the least, because it is usually taught as vocabulary. Three corrections make it stick:
- Learn the failure before the fix. Nobody invented semaphores for fun; they exist because two threads incrementing a counter can lose an update. Reproduce that failure in your head — instruction by instruction — and the primitive becomes obvious instead of arbitrary.
- Always ask "who is blocked, and who runs instead?" Almost every OS mechanism is about what happens to the CPU while something waits. If you can answer that for page faults, I/O, locks and syscalls, you understand most of the subject.
- Connect every concept to something you can observe. Page faults
are a column in
ps. Context switches are a line invmstat. A deadlock is a process in stateD. Theory you can point at in a terminal is theory you will remember under pressure — and that is what senior interviewers probe.
Not whether you can recite the five process states. They want to know whether you'll be able to debug a production incident: why is this service using 40 GB of RAM, why is it stuck at 100% CPU with no throughput, why did it die at 3am and leave no log. Every topic page ends with the failure signature you'd actually see.
The 22 topics
Basics — the machine underneath
Concurrency — where the bugs live
Memory — the biggest illusion in computing
Storage, I/O and the rest of the machine
The interview section has a 60-question bank with full answers, the four question formats OS gets asked in (definition, numerical, trace-the-code, debug-the-box), a Linux debugging drill, and the answers to the questions that get asked in almost every round.
The 22-day plan
One topic a day. Tick a day when you can explain it out loud and name what it costs. Progress is stored in this browser only.
The one big idea
If you remember a single sentence from this subject: the OS lies to every program, consistently, and hardware helps it keep the lie.
Numbers worth memorising
The mistakes that cost marks
- "Threads have their own memory." They share the heap — that's the whole point and the whole danger.
- "Virtual memory means using disk as RAM." Swap is one consequence; virtual memory is address translation and isolation.
- "A deadlock is when the system hangs." Deadlock is a specific four-condition cycle. Livelock and starvation also hang, differently.
- "More threads means more speed." Past the core count you're adding context switches and lock contention.
- "LRU is optimal." Optimal needs the future. LRU approximates it and loses badly to a sequential scan.
- Confusing preemptive with priority-based.
- Saying "semaphore" when you mean "mutex" — ownership is the difference.
- Mixing internal and external fragmentation.
- Treating paging and swapping as synonyms.
- Describing a container as "a lightweight VM" — it shares the host kernel, which is the entire security story.
"Round robin bounds the waiting time so nothing starves, which is what you want for interactive work. The cost is throughput: every quantum boundary is a context switch, and if the quantum drops near the switch cost you spend a meaningful share of the CPU on switching rather than working. So the quantum is a dial between responsiveness and overhead — typically a few milliseconds, which is far above the microsecond switch cost."