96 topics · 4 subjects · ~250 interview answers
Everything you need for a CS fundamentals interview, in one place
Four guides built the same way. Every topic answers why it exists, what it costs you, and what you say when an interviewer asks — because the exam question and the interview question are rarely the same question.
The four subjects
How to use these
The same three steps work for all four subjects, and they are deliberately not "read the guide twice".
- Take one topic and find the problem it solves. Paging exists because programs need more address space than you have RAM. TCP's congestion control exists because the internet collapsed in 1986 when it didn't have any. Normalisation exists because duplicated facts drift apart. Learn the failure first and the mechanism stops being something to memorise.
- Explain it out loud, without notes. Every topic has a "Say this" box — a scripted answer at interview length. Read it once, then say your own version to an empty room. The gap between recognising an explanation and producing one under pressure is the entire interview.
- Answer the bank cold. Each subject ends with a question bank where the answer is collapsed. Answer before you open it. If your answer is missing the tradeoff or the failure case, that's the gap — not the definition.
After any mechanism you describe, finish with "…and the cost of that is ___." LRU costs you bookkeeping and dies on a scan. An index costs you write throughput. TCP costs you head-of-line blocking. Normalisation costs you joins. Interviewers are grading whether you know the price, because anyone can name the feature.
What to study first
If you have limited time, the subjects are not equally weighted for every role.
| If you're interviewing for… | Priority order | Why |
|---|---|---|
| New grad / campus placement | DBMS → OS → Networks → System Design | Core-subject rounds and written tests weight the classical three heavily; system design is usually light or absent. |
| Backend / SDE-1 | DBMS → System Design → OS → Networks | You will be asked to write SQL and reason about indexes and transactions almost certainly. |
| Senior backend | System Design → DBMS → Networks → OS | The design round dominates the decision; the others show up as depth probes inside it. |
| SRE / DevOps / platform | OS → Networks → System Design → DBMS | Debugging rounds are Linux and TCP. "The service is slow, here's a terminal" is the format. |
| Systems / embedded / kernel | OS → Networks → DBMS → System Design | Concurrency, memory and scheduling get asked in real depth here. |
Where the four subjects connect
These are not four separate syllabi. The same handful of ideas keeps reappearing under different names, and noticing that is what makes the fourth subject much faster to learn than the first.
| Idea | In OS | In Networks | In DBMS | In System Design |
|---|---|---|---|---|
| Caching a slow layer | TLB, page cache, CPU caches | DNS cache, browser & CDN cache | Buffer pool | Redis, CDN |
| Locking & conflict | Mutexes, semaphores, deadlock | — | 2PL, MVCC, isolation levels | Distributed locks, fencing tokens |
| Write-ahead logging | Journaling file systems | — | WAL, ARIES recovery | Kafka, event sourcing, outbox |
| Flow & overload control | Scheduler queues, cgroups | TCP flow & congestion control | Connection pools, admission control | Rate limiting, backpressure |
| Indexing for lookup | Page tables, inode maps | Routing/forwarding tables | B+ trees, hash indexes | Inverted index, geospatial index |
| Retry & duplicate safety | Interrupted syscalls (EINTR) | TCP retransmission | Idempotent statements | Idempotency keys, at-least-once |
| Fragmentation | Internal/external memory fragmentation | IP fragmentation, MTU | Page splits, table bloat | Hot shards, uneven partitions |
| Layered abstraction | Syscall boundary, VFS | OSI / TCP-IP stack | Three-schema architecture | Service tiers, API contracts |
When an interviewer asks something you half-know, reach for the analogue you know well. "A buffer pool is doing the same job as the OS page cache, with the database choosing eviction because it knows the access pattern better than the kernel does" is a genuinely strong answer — it shows you understand the mechanism, not just one instance of it.
The last week before an interview
Reading is the wrong activity in the final week. Retrieval is the right one.
| Day | Do this |
|---|---|
| −7 | Read the four cheat sheets end to end. Note every line that surprises you; those are your gaps. |
| −6 | Work the gaps only. Go to the topic page for each surprise, not the whole subject. |
| −5 | DBMS question bank, cold, out loud. Then write three SQL queries by hand on paper. |
| −4 | OS question bank cold. Then explain deadlock and virtual memory to someone non-technical. |
| −3 | Networks question bank cold. Then talk through "what happens when you type a URL" without stopping. |
| −2 | One full 45-minute design mock, timed, on paper, speaking the whole time. |
| −1 | Cheat sheets once more. Nothing new. Sleep — recall degrades faster from tiredness than from a missing topic. |