Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
Most people prepare for system design the way they prepare for a vocabulary test: memorise a list of components, learn which famous company uses which database, and hope the right one comes up. That preparation fails in a specific, predictable way — you produce a design that is technically plausible and completely unmotivated. You put a queue in because designs have queues in them, not because you identified a producer that is faster than its consumer. The person on the other side of the table is not checking whether you know Kafka exists. They are checking whether you can be handed a deliberately vague problem, ask the questions that shrink it, commit to a shape, and then defend that shape when they push on it — because that is the same thing you will be asked to do in your first week on the job. This module teaches the reading method the rest of the course applies: how to see a design as a set of decisions that each cost something, rather than a picture with boxes in it.
A 45-minute design conversation has a shape, and most candidates lose it in the first ten minutes by drawing before counting. Here is the arc that works, followed by the rubric people are actually scored against.
The critical move is at minute five: you state numbers before you draw anything. Numbers are what make every later decision defensible. If you have said out loud that this system takes roughly 300 reads per second at peak, then a sharding discussion is obviously premature and you can say so — confidently, with a reason. If you never said a number, every component you add is equally arguable and equally unmotivated, and the conversation drifts into trivia.
Notice what is not on the rubric: knowing the exact name of a product, remembering a specific configuration flag, or reciting an architecture from a company blog post. Those are recall. The rubric is judgement.
# What a system design conversation is scored on.
# Nobody scores you on vocabulary. Four axes, 0-3 each.
scoping:
question: Did you shrink an open-ended problem to something designable?
0: started drawing immediately
1: asked questions, then designed something wider anyway
2: named 3 features in scope and said what was out
3: also said which cut would change the design most, and why
quantification:
question: Did numbers arrive before components?
0: no numbers at all
1: numbers stated but never used
2: numbers drove at least one component decision
3: a number ruled a component OUT ("300 rps, so no sharding yet")
justification:
question: Does every box have a reason?
0: components named from memory
1: reasons given when asked
2: each component introduced with the property it buys
3: also the cost it charges (staleness, ops surface, money)
pressure_response:
question: What happens when the design is pushed?
0: added more components
1: changed something plausible
2: named the bottleneck first, then changed one thing
3: also stated what deliberately did NOT change, and why
# Rough read: 8+/12 is a strong signal. Most failures are a 0 or 1
# in 'quantification' dragging everything else down.