Most failed design rounds are not lost for lack of knowledge. They are lost to process: a design started before the problem was agreed, numbers that changed nothing, a hint that went past, a deep dive that never began. This chapter catalogues twenty mistakes in the order they happen in a round. For each: how it shows up in the room, why it costs the hire decision, the fix, and a short before-and-after. It ends with a protocol for reviewing a mock and a checklist to tick against every recording.
How a mistake becomes a no-hire
The interviewer cannot score what you know, only what they saw and heard. Their notes become written feedback against a handful of dimensions (the five things interviewers score), and the feedback goes to a debrief or a hiring committee. A mistake damages that record in one of two ways:
- Negative evidence. Something wrong is on the record: a component with no reason, a claim that does not hold ("exactly-once, so no duplicates"), a wrong number that led to a wrong design.
- Missing evidence. A dimension has nothing in it, because the clock ran out or you never went there. "No data on failure handling" scores low even if you could have answered perfectly.
Missing evidence is the more common killer, because mistakes compound through time. Five minutes lost to a jump-start or a wrong estimate in the first fifteen are five minutes of deep dive that never happen in the last fifteen, and the deep dives are where depth, and at Senior and above much of the level, is decided. That is also why the fixes below share a theme: say things early, out loud, in a form the interviewer can write down.
Some mistakes are cheap if you catch them live. A unit slip corrected aloud reads as rigour. Others cannot be repaired after the fact: running out of time, or a hint that was never taken. Each entry below has a one-line recovery for when you notice it mid-round.
The twenty at a glance
| # | Mistake | Phase | Mainly damages | Spot it in a recording by |
|---|---|---|---|---|
| 1 | Jumping to a solution | Scope | Navigation | First box drawn before any requirement was agreed |
| 2 | Reciting a memorised design | Scope | Navigation, design | The famous design delivered; the prompt's twist never named |
| 3 | No numbers, or numbers that change nothing | Estimate | Design | No sentence of the form "N, so we do X" |
| 4 | Unit slips in the estimate | Estimate | Design, depth | Per day used as per second; bytes and bits mixed |
| 5 | Skipping the API and data model | API, data | Design | No partition key said aloud before the diagram |
| 6 | One database for everything | Design | Design, depth | Blobs, queues and counters all in one relational store |
| 7 | Over-engineering for small scale | Design | Design, operations | Queues, shards or regions with no number behind them |
| 8 | Under-engineering at Google scale | Design | Depth, operations | One region, one database, "add more servers" |
| 9 | Naming products instead of mechanisms | Design | Depth | A product name with no property or cost after it |
| 10 | A diagram nobody walks through | Design | Design, depth | No numbered request traced through the boxes |
| 11 | Going deep on the wrong thing | Deep dive | Depth | Ten minutes on a commodity component |
| 12 | Options without a decision | Deep dive | Depth, design | "It depends" with no choice after it |
| 13 | Consistency words without user-visible behaviour | Deep dive | Depth | "Eventually consistent" with no statement of what a user sees |
| 14 | Ignoring failure modes | Deep dive | Operations | Failure raised only by the interviewer |
| 15 | Ignoring cost and operations | Deep dive | Operations | No cost line, no SLI, no rollout plan |
| 16 | Monologuing, or going silent | Any | Communication | A stretch of more than three minutes with no question |
| 17 | Not checking in | Any | Communication, navigation | Assumptions made silently; scope never confirmed |
| 18 | Ignoring the interviewer's hint | Any | Communication, depth | The same question asked twice |
| 19 | Digging in when challenged | Any | Communication | A challenge answered by repeating the claim |
| 20 | Running out of time | Wrap-up | Depth, operations | No deep dive started by minute 30; no summary |
The examples use one prompt throughout, the pastebin worked in How to drive a design, so the before-and-afters can be compared against a full run.
Scoping
1 · Jumping to a solution
In the room. Boxes appear in the first two minutes: "Clients, a load balancer, app servers, a database, object storage." The first question asked is about the technology stack.
Why it costs. Navigation, the first dimension, gets no evidence. The design is then judged against requirements the interviewer had in mind and you never heard, and when one surfaces at minute 25 (unlisted pastes must not be guessable) the design is reworked on the clock.
Fix. Spend three to five minutes on questions whose answers change the design, write in and out lists, and get agreement before the first box. If you catch it live: "Let me step back; I've started drawing before we agreed what this must do. Two minutes on requirements."
Before
"Pastebin. So: clients hit a load balancer, then app servers, then MySQL, and the text goes to object storage."
After
"Before I draw: can anyone with the link read a paste, or are some private? What's the size limit? Do pastes expire? Can they be edited? ... So: create, read, expire; public and unlisted; no edits. Does that match?"
2 · Reciting a memorised design
In the room. The prompt resembles a famous one, and the candidate delivers the famous answer. "Design a pastebin" gets the URL-shortener design with sequential ids; "design Instagram" gets a feed when the interviewer wanted the upload pipeline.
Why it costs. Interviewers sometimes change one requirement from the famous version to see whether you notice. A recited answer misses it, and the "why" follow-ups expose that the structure came from memory rather than from this problem's needs.
Fix. After scoping, say in one sentence what is different about this prompt from the version everyone knows, and let that property choose the deep dives. If you catch it live: "This looks like X, but the difference is Y, so let me design around Y."
Before
"I'll do what a URL shortener does: a counter, base-62 encoded, with id ranges handed to each server."
After
"The usual shortener answer uses sequential ids. Here that breaks unlisted pastes, because sequential keys can be enumerated. So keys must be random, and long enough for the number we'll issue."
Numbers
3 · No numbers, or numbers that change nothing
In the room. "It has to scale, so we'll shard and cache." Or the opposite: a careful estimate on the board, followed by a design that would be identical at a thousandth of the size.
Why it costs. Numbers are how the interviewer checks that each component is justified. Without them every component is a guess, and the design reads as pattern-matching. Computing numbers and then ignoring them is worse than skipping them: it shows you know the ritual and not its purpose.
Fix. Compute only the numbers that can change a decision (peak rate per operation, bytes per day, a latency budget, a cost), and end each one with "so". If you catch it live: "Let me size this before going further; I've added a cache without knowing the read rate."
Before
"Say 10M users, so a lot of traffic. We'll need caching and sharding."
After
"50 writes a second and 5,000 reads at peak. Writes fit one primary with headroom, so no write sharding. Reads are spiky and the content is immutable, so cache at the edge. Bytes are 50 GB a day against 1 GB of metadata, so they go to different stores."
4 · Unit slips in the estimate
In the room. A per-day figure divided as if it were per-second; megabytes and megabits mixed; a yearly total that forgot the 365 or the replicas; average used where the peak decides.
Why it costs. A slip of a thousand times produces a design for a different system: sixteen shards for 50 writes a second. The interviewer must then decide whether to stop you. If they do, it goes in the notes as prompted; if they don't, everything built on the number is wrong.
Fix. Write the unit on every line, round on purpose and say so (86,400 seconds to 100,000), and finish with a magnitude check against something you know, such as "one database primary handles thousands of simple writes a second". If you catch it live, correct it aloud and follow the consequence through; that reads as rigour.
# before bytes 5M pastes/day x 10 KB = 50 MB/day <- M x K is G, not M egress 5,000/s x 10 KB = 50 MB/s = 50 Mbps <- bytes are 8 bits # after bytes 5 x 10^6 x 10^4 B = 5 x 10^10 B = 50 GB/day egress 5,000/s x 10^4 B = 5 x 10^7 B/s = 50 MB/s = 400 Mbps