You can read every lesson in this course and still stumble in the room if you have never performed a design out loud. System design is a skill you rehearse, not a body of facts you memorize. This lesson is the plan: how the round actually works, what to study and in what order, and how to practice so that the real interview feels familiar.
Why this round is different
A coding interview has a right answer and a test harness. A system design interview has neither. The interviewer hands you a deliberately vague prompt — “design Twitter” — and watches how you turn ambiguity into a concrete, defensible architecture.
That changes what you are preparing for:
- It is a conversation, not a monologue. You are being evaluated as a future colleague in a design review. Long silences and rehearsed speeches both hurt you.
- There is no single correct design. Two strong candidates can produce different architectures and both get a “hire.” What matters is that your decisions follow from the requirements.
- Breadth and depth both count. You must sketch the whole system and go deep on the one or two hardest parts.
- You drive. Weak candidates wait to be prompted. Strong candidates set the structure, manage the clock, and pull the interviewer in as a collaborator.
If the first lesson is what is scored, this lesson is how to get good at it.
A four-week plan
Four weeks at roughly an hour a day is enough to go from shaky to solid, assuming you already know the basics of web systems. Compress or stretch it to fit your timeline, but keep the order: concepts before problems, problems before mocks.
| Week | Focus | What to do |
|---|---|---|
| 1 | Framework + estimation | Learn the 4-phase framework until it is automatic, and drill back-of-the-envelope estimation until QPS and storage math are fast. |
| 2 | Concepts, tech, patterns | Work through the core-concept lessons (networking, databases, caching, sharding, replication) and the reusable patterns. Build the mental index of which tool for which requirement. |
| 3 | Design problems | One full problem per day, out loud, timed to ~40 minutes. Start with the classics (chat, URL shortener, news feed) and progress to the harder ones (ride-sharing, payments, ad-click aggregator). |
| 4 | Mocks + weak spots | Two or three mock interviews with a peer or a platform, plus targeted review of whatever kept tripping you up. Re-read Mistakes That Kill Your Interview. |
Week 1 — make the framework automatic
The framework is your safety net under pressure. When your mind goes blank on an unfamiliar prompt, the framework gives you the next move: clarify requirements, estimate scale, sketch the high-level design, then deep-dive. Practice it on a single problem until you can run all four phases without thinking about the structure — so that in the room, all of your attention is free for the actual engineering.
Estimation deserves its own reps. You should be able to turn “500M daily active users, 2 posts each” into writes-per-second and storage-per-year in under a minute, because those numbers justify every later decision (do we need sharding? a cache? a CDN?).
Week 2 — build the toolbox
You cannot reason about trade-offs between tools you do not understand. Spend this week making sure you can answer, for each major component, what it is good at and when you would reach for it: SQL vs NoSQL, when to add a cache, how sharding and replication actually work, when a message queue earns its place. The goal is not memorizing architectures — it is building the index that lets you retrieve the right building block on demand.
Week 3 — perform, do not read
This is the week that matters most, and the one most people skip. Reading a worked solution is not practice; producing one is. Pick a problem, set a 40-minute timer, and talk through the entire design as if someone were watching — ideally while sketching on a whiteboard or a blank document. Record yourself if you have no partner. You will discover that the parts you “understood” while reading collapse when you have to generate them live. That gap is exactly what the interview exposes, and closing it is the whole point of week 3.
Week 4 — mocks and triage
Nothing simulates the real thing like a mock with a human who pushes back. Do a few, and after each one write down the single biggest weakness it revealed, then spend a session fixing it. By now you are not learning new material; you are smoothing the rough edges.
How to practice out loud
- Narrate everything. State requirements, say the numbers, announce your plan before drawing. Silence reads as being stuck.
- Use a timer. The real round is ~40–45 minutes. Practicing untimed hides your worst habit: spending 20 minutes on requirements and running out of time before the deep dive.
- Draw as you talk. A whiteboard or a shared doc forces you to commit to an architecture and makes the conversation concrete.
- Invite pushback. Have your partner ask “why not X?” and “what happens when this fails?” — the two questions real interviewers lean on hardest.
What each level is expected to deliver
Interviewers calibrate to the role. The same answer is scored differently depending on the bar.
| Level | What a “hire” looks like |
|---|---|
| Mid | Covers the breadth: gathers requirements, produces a reasonable end-to-end design, and can justify the main component choices. |
| Senior | Adds depth: drives the conversation, goes deep on the hard parts (the data model, the bottleneck), and reasons clearly about trade-offs and failure modes. |
| Staff+ | Leads the design: scopes aggressively, anticipates second-order problems, weighs operational and organizational cost, and treats the interviewer as a collaborator rather than an examiner. |
The day before
- Re-read the framework and your estimation cheat-sheet; those are your two reflexes.
- Do one light, full mock to warm up — not a cram session.
- Prepare your environment: a reliable drawing tool you have used before, a quiet space, water. Fumbling with an unfamiliar whiteboard app in the first two minutes is an avoidable own-goal.
- Sleep. A rested brain recovers from a stumble; a tired one spirals.
Key takeaways:
- System design is a performance skill — rehearse it out loud and timed, do not just read solutions.
- Follow the order: framework and estimation first, then concepts and patterns, then whole problems, then mocks.
- Week 3 (daily timed problems, spoken) is the highest-leverage week; do not skip it.
- Calibrate to your target level: breadth for mid, depth for senior, leading the design for staff.
- The framework is your safety net — make it automatic so your attention is free for the engineering.