Practising, and marking your own work
Run a timed mock against yourself, score the transcript on a six-row rubric, and climb a practice ladder from worked designs to unseen problems.
Reading a worked design and producing one on a clock are different skills, and only the second is scored. The gap shows up as articulation failure: a candidate who can define consistent hashing cannot narrate the decision to use it inside a 45-minute budget while somebody watches and takes notes. Practice only closes that gap if it reproduces the conditions — timed, spoken aloud, at a surface another person could read.
Run the attempt like the round
Set four timers from the four-step framework: 8 minutes to scope, 5 to estimate, 15 for API and boxes, 15 for the deep dive. That is 43 minutes, leaving 2 for the interviewer's opening and the closing questions. The alarms are the point — the budget is what candidates blow, and you cannot train a budget you never hit.
Three rules separate practice from re-reading:
- Out loud, in full sentences. Speech runs about 130 words per minute, so 43 minutes is roughly 5,600 words of continuous narration. That is the load being tested, and silent practice trains none of it. Thinking "yes, hybrid fan-out" while your eyes move down the page rehearses recognition, which you already have.
- At a whiteboard or a shared doc, standing, drawing while you talk. Drawing and speaking compete for attention; discovering that during the round is expensive.
- Solution covered. Once you have seen the answer, the attempt measures memory instead of judgment.
The rubric
Score yourself immediately after the attempt and before uncovering the solution, while the transcript is still in your head. Six rows, 0 to 2 each, 12 total. Each row is one of the things the round actually measures.
| # | Question | 0 | 1 | 2 |
|---|---|---|---|---|
| 1 | Did I leave Step 1 with numbers? | Adjectives only — "high scale" | DAU stated, nothing else | DAU, actions/user/day, read:write ratio, payload size |
| 2 | Did I produce an API before boxes? | Drew boxes first | Named endpoints, no signatures | 3-5 endpoints with request and response shapes, then the data model |
| 3 | Did I name three trade-offs with the rejected alternative? | Choices asserted | Alternatives named, no cost stated | Three or more in the four-part form: choice, constraint, cost accepted, reversal condition |
| 4 | Did I hit the bottleneck my estimates predicted? | Deep-dived somewhere arbitrary | Found it after a hint | Went there unprompted and said which number sent me |
| 5 | Did I go three levels deep on one component? | Box and a label | Box and its algorithm | Box, algorithm, failure behaviour, and the arithmetic that sizes it |
| 6 | Did I finish? | Ran out mid-Step 3 | Deep dive rushed into the last 3 minutes | All four steps inside 45 minutes with a summary |
First attempts usually land at 4-7 of 12, and the shape is consistent: a 2 on boxes, a 0 on numbers, a 0 on finishing. Two consecutive 10s on unseen problems is the readiness signal. Log the total after every attempt; the trend carries the information, and a row stuck at 0 or 1 across three attempts is a reading gap, not a practice gap. Row 3 at 0 means saying the trade-off out loud; row 1 at 0 means back-of-the-envelope estimation.
What the recording shows
Record the audio — video adds little. Play it back at 1.5x, which turns 45 minutes into 30, and mark three things:
Filler. Count "um", "basically", "kind of" and "sort of" in one 5-minute stretch and multiply by 8.6 to get the session total. At 3% of 5,600 words that is about 170 instances, and every one of them is a second not spent on the design. The cure is not fluency drills, it is a decided sentence: filler clusters where you are still choosing while already speaking.
Silence longer than about 10 seconds. Under 10 s reads as thinking. Past it the interviewer cannot tell whether you are working or stuck, and their only options are to wait or to hint — both of which cost you. Narrate the search instead: "I am deciding between a queue and a synchronous call here; let me size both."
Unexplained jumps. You say "so we shard by user id" and nothing earlier in the recording introduced sharding. Standing at the board it felt continuous, because the reasoning happened silently. On tape it is a jump, and each one is a place the interviewer marked down a decision with no argument attached.
Practising with a partner
Interviewing someone else is the fastest way to improve, because the failure modes are obvious from the scoring side and they are the same ones you commit. Twenty minutes of watching a partner draw boxes before asking about scale does more for your Step 1 than a lesson on Step 1.
To be useful as the interviewer: answer scale questions with numbers, and refuse every question that asks you to design. Push on the weakest component, not the one they are enjoying — the round is a search for the depth limit. Ask "what breaks first at 10x?" and "at what number does this stop working?" Hint on a schedule rather than out of sympathy: 60 seconds of silence buys one nudge toward the area, another 60 buys the component name. Then score them on the rubric above and compare with their self-score. The gap between the two scores is the most useful artefact of the session, because it is exactly the calibration error you carry into the real round.
The practice ladder
Rung 1 — the eight worked designs, solution covered. URL shortener, rate limiter, news feed, chat, notification system, ride matching, image and video delivery, search autocomplete. Attempt, score, then read the lesson as the mark scheme.
Rung 2 — variants that change exactly one constraint. The same feed, but strictly chronological across 10,000 followees. Work the arithmetic and the design moves on its own: 10,000 followees × 2 posts/day = 20,000 posts/day into one feed, or 20,000 ÷ 24 ≈ 833 per hour, so the 500-entry cap from the news feed holds 500 ÷ 833 ≈ 0.6 hours of history. Scroll past 36 minutes and every page falls through to a pull. Holding a day instead costs 20,000 × 20 bytes = 400 KB per feed against 10 KB — 40× — and ranking is no longer available to hide the staleness, because the order is fixed. Other one-constraint variants: the shortener with custom aliases and a global uniqueness check; the rate limiter with a hard guarantee instead of an approximate one; chat with a 100,000-member group.
Rung 3 — unseen problems, cold. No reading first, no solution to check against. Score on the rubric alone, which is the point of having a rubric that does not depend on knowing the answer.
Problems without solutions
Each names the constraint that makes it interesting; work them cold.
- A payment wallet ledger. Double-entry, exactly-once semantics over an at-least-once transport, and a balance that must never go negative under concurrent debits.
- A job scheduler. Cron at 100,000 jobs, and what happens when a worker dies mid-execution — see idempotency.
- A collaborative document editor. Concurrent edits, offline clients, and convergence without a lock.
- A metrics and monitoring pipeline. 1M hosts × 100 metrics every 10 s = 10M writes/second, and a query layer over that.
- A multi-tenant control plane. Noisy-neighbour isolation, per-tenant limits, and a rollout that cannot take every tenant down at once.
- A distributed cache. Placement, rebalancing on node loss, and the invalidation problem from caching.
- A ticket-booking system. Fixed inventory, a 10-second hold, and 50,000 people arriving for 5,000 seats.
In an interview
Nobody asks about your practice routine. What arrives in the room is the budget: a candidate who has run the clock ten times says "I have used about eight minutes on scope, so let me size this" without looking at the wall, and an interviewer reads that as someone who has run projects. The rubric rows are what the scoresheet asks, in the order it asks them.
The mistake that loses points is practising the part you are already good at. Drawing the same high-level diagram for the eleventh time feels productive and moves nothing; the score log exists to stop you, because it names the row you keep failing. Twelve attempts at rung 1 with a 6 every time is a worse investment than three attempts at rung 3 with a partner who pushes.
Check yourself
1. You have 14 days and 45 minutes a day. A full session is 45 minutes plus 15 to score and log, so daily attempts do not fit. What schedule, and which rungs?
14 × 45 = 630 minutes total. A full session costs 60, so 7 sessions consume 420 and leave 210 minutes. Alternate: 7 timed attempts on odd days, and on even days spend the 45 minutes re-reading whichever rubric row scored lowest. Spend sessions 1-3 on rung 1, 4-5 on rung 2 variants, 6-7 on unseen problems from the list above — the readiness signal lives on rung 3, so ending on rung 1 tells you nothing you did not already know.
2. Three attempts in, you score 9, 10, 9 out of 12, and both lost points every time are on row 6, finishing. Everything else is a 2. What do you change?
Not the material — rows 1 to 5 at 2 means the knowledge is there. Cut Step 3. Scoring 2 on rows 2 to 5 while running out of clock means the high-level design is being over-drawn: too many boxes, each explained. Draw five boxes in 15 minutes, name the bottleneck, and move. A rushed deep dive costs more than a thin diagram, because rows 4 and 5 are where senior signal is read.
3. Your partner scores you 7 on an attempt you scored 10 on. Which number do you record, and what does the gap mean?
Record the 7, and record the gap as its own line. Your partner is the closer simulation — they only heard what you said, while you scored what you meant. A consistent 3-point self-inflation is an articulation gap, not a knowledge gap, and it is exactly what the recording playback diagnoses: the jumps you cannot see are the ones your partner scored a 1 on.