13 questions · 6 tracks · free
System Design Interviews, Answered Out Loud
Every question run as a real interview: ask before you draw, size it, put the boxes up one at a time, then name what you would give up — and each one ends with the follow-up that separates a rehearsed answer from a real one.
Most system design preparation is a list of architectures to memorise, which is why so many candidates draw boxes for a problem nobody described. An interview is a conversation: you ask what it has to do and for how many people, you size it, you put up the smallest thing that works, and then you say what it costs. Every question below is laid out in that order — the questions to ask first, the answer in four moves, and the trap at the end — so it is practice, not a diagram to copy.
The fundamentals underneath these answers are the free CS course, and you can ask the blog about anything already published.
Start with clarify before you drawT01How to run the interview
Four moves that are the same in every question. Learn these and the questions below stop being thirteen problems and start being one.
T02Store it and serve it
Questions where the bytes are the problem: how they are keyed, where they physically live, and who pays to move them.
T03Deliver it to people
Questions about getting a message to the right person at the right time — where the hard part is always the fan-out and the duplicate.
T04Find it
Questions where the answer is an index built before the request arrives — search, crawling, and finding the nearest thing on a map.
T05Protect it and charge for it
Questions where correctness beats throughput: limiting abuse, taking money, and the cache everyone reaches for without saying how it is keyed.
T06Design the objects, not the boxes
One question from the other family. It looks like system design and is graded like object-oriented design — and answering the wrong one is the whole trap.