Most candidates who fail a system design round knew enough to pass it. They lose because, at the moment it mattered, the interviewer could not write down evidence for one of the scored signals, or wrote down evidence against it. This page catalogues those moments: 23 mistakes grouped by phase, what each looks like from the interviewer’s side of the table, which signal it costs, and the repair you can make while the round is still running.
Picture it first: the driving test
A driving examiner sits beside you with a marking sheet. Few candidates fail because they can’t steer. Some check the mirror with their eyes only; the examiner never sees it, and the box stays unticked. Others commit a fault that goes on the sheet, such as rolling over a stop line.
Good drivers make mistakes too. One stalls at a junction, restarts calmly and carries on, and that calm is evidence of control. Arguing about whether the stop line was really there turns a minor fault into a serious one.
Map it back:
- The marking sheet is the interviewer’s rubric: a few signals, each needing evidence.
- The silent mirror check is reasoning you never said aloud. It was right, and it scores nothing.
- The stop line is a red flag, such as a single point of failure you never noticed.
- The calm restart is a mid-round correction; the argument is defending a choice a number has ruled out.
Why rounds are lost
Interviewers write notes against a few signals: problem navigation, solution design, depth and trade-offs, scale and failure, and communication. Meta’s guide names four focus areas; splitting its “technical excellence” into depth and failure helps here, because candidates often show one without the other. A signal is lost in one of two ways:
- No evidence. You did the reasoning but never said it, or never reached the part of the round where it shows. One blank signal can cost an offer or a level.
- Evidence against. You said something the interviewer must record as a concern: eventual consistency for a wallet, one database with no failover, “collisions are rare” when the arithmetic says 500 a day.
Google’s re:Work guide describes structured interviewers “recording comprehensive feedback” and scoring it against poor-to-outstanding rubrics, partly because, left alone, interviewers hunt for evidence that confirms a first impression. That helps you: a shaky opening can be outweighed by clear evidence later, if someone can write it down.
Not knowing a product isn’t on the list. Meta’s guide says “it’s ok if you don’t know”; gaps get expensive only when you bluff. An Amazon senior engineer says that when candidates claim an esoteric database feature is required, “I usually ask them to design that part in detail”.
| Signal | Lost by silence | Lost by a red flag |
|---|---|---|
| Problem navigation | No requirements or numbers on the board | Ignoring a stated requirement |
| Solution design | No request traced end to end | A flow that can’t work |
| Depth and trade-offs | Everything one level deep; no choices | Defending a choice a number ruled out |
| Scale and failure | Failure never mentioned; no peak | A SPOF the interviewer had to point out |
| Communication | Long silences; no plan; no wrap-up | Arguing with hints |
Where mistakes happen and where they cost you
Most mistakes are made in the first half of the round and billed in the second. A requirement you never asked about costs nothing at minute 4 and everything at minute 30, when the curveball lands on it. A unit slip at minute 13 stays invisible until a deep dive leans on the number. That lag is why a round can feel fine for 20 minutes and then come apart.
So fix mistakes where they’re made; that’s what the delivery framework’s checkpoints at minutes 15, 25 and 35 are for. When something breaks late, look upstream first, in the requirements corner.
Scoping mistakes
Scoping mistakes are cheap to make and expensive to discover, because everything later is built on them.
Drawing before asking
Within a minute of “design a ticket-booking system”, a load balancer, three services and a database are on the board, and problem navigation has nothing under it. Amazon’s system design prep video opens with “don’t jump into solving the problem”; Microsoft’s tips say to “come up with a plan before you implement a solution”.
Costs: problem navigation now, solution design later. Repair: “Let me step back; I drew before we agreed what we’re building.” Ask who uses it, what they do and when the peak lands, and write the answers in a corner.
Adjectives instead of numbers
“Scalable, low latency, highly available” describes every system and constrains none. Meta’s guide counts understanding what “is needed for quantitative analysis” as part of problem navigation.
Costs: problem navigation, then depth, because without a number you can’t justify a cache or a shard. Repair: make each adjective testable (“search p95 under 300 ms”, “bookings 99.9% a month”) and ask whether it’s off by 10×.
No out-of-scope line
Payments, refunds, notifications, admin and analytics all get a box. At minute 30 everything exists and nothing has depth.
Costs: depth, spread thin. Repair: name three things you won’t design and what you assume instead, such as “an existing payment service with a callback”, and check the assumption with the interviewer, as Amazon’s video advises.
Requirements written, then forgotten
“Never double-book” is on the board at minute 6; at minute 25 the design decrements a cached counter and writes the booking asynchronously. Amazon’s development manager describes exactly this: requirements gathered but “not using them in the design”.
Costs: solution design, as a red flag. Repair: at the end of each phase, read the corner aloud and point to the box that satisfies each line.
Missing the question that shapes the design
You asked about users and features, but not what picks the architecture: a URL shortener’s read-to-write ratio, a tatkal booking’s 10 am burst, a wallet’s never-wrong operation, a feed’s fan-out.
Costs: problem navigation, which Meta frames as identifying “the most critical problems”. Repair: ask where the peak is, how reads compare with writes, and which operation can never be wrong. The answers pick your first deep dive.
Estimation mistakes
Estimates exist to pick boxes. These mistakes pick nothing, or the wrong box.
Numbers disconnected from decisions
Ten minutes on five years of storage for data that fits on one disk; or no numbers at all, then “we’ll shard it”. Google’s SRE Workbook puts “sound reasoning and assumption making” above “any final values”: a number matters only for what it settles.
Costs: depth, plus minutes. Repair: say what the arithmetic decides before you start, and skip it out loud if no answer would change the design. See back-of-envelope estimation.
Unit slips worth 10×
A day taken as 10⁴ seconds instead of about 10⁵; bytes read as bits; kilobytes typed as megabytes. Each slip is 8× to 1,000×, and it lands on the wrong side of a threshold.
Costs: depth, and a red flag if the interviewer catches it first. Repair: units on every line, and a sanity check against numbers to know: one server’s requests, one primary’s writes, one network card.
Sizing for the average
“1.2 million bookings a day is 14 a second; easy.” Twitter reported a one-second peak of 143,199 tweets in 2013 against an average of about 5,700: roughly 25×. A tatkal window packs a day’s demand into minutes.
Costs: scale and failure: the design falls over exactly when it’s needed. Repair: ask when traffic arrives, and compute a burst from the event (users × requests ÷ window), not the day.
Mistakes in the high-level design
Here the interviewer checks that something works at all. These mistakes produce a finished-looking diagram you can’t defend.
Buzzword stacking
Kafka, Redis, Kubernetes, Cassandra and MongoDB by minute 12, none tied to a requirement. Asked why, the answer is “for scale”, and every technology you name invites a request to design it.
Costs: solution design and depth, as a red flag. Repair: every box earns a requirement or a number; remove what doesn’t. “Kafka comes off: at 35 writes a second nothing needs buffering. If we add click analytics, it comes back.”
Boxes nobody traced
“Walk me through what happens when a user taps Book,” and the path runs through a service with no API, or reads from a store that nothing writes.
Costs: solution design: no evidence it works. Repair: trace each functional requirement aloud, numbering the arrows: endpoint, service, write, response.
A database with no reason
“We’ll use Cassandra”, before anyone knows the access patterns.
Costs: depth and trade-offs. Repair: access pattern first, then the store: “A booking updates a seat and a payment status together, so a relational database keyed by booking ID.” See databases for system design interviews.
The single point of failure you drew yourself
One database, one cache node, one ID allocator, never mentioned. An Amazon senior engineer calls “forgetting about availability” one major mistake he sees; the SRE Workbook asks of every design, “What happens when this component fails?”
Costs: scale and failure, a red flag if you had to be prompted. Repair: name the single point of failure first, what users see when it dies, and the fix with its cost.
One consistency model for everything
“Everything is eventually consistent”, wallet debits included. Or strong consistency for like counts, paying latency for nothing.
Costs: depth; the first version is a red flag, because it can lose money. Repair: choose per operation by asking what a wrong answer costs against no answer. See CAP and PACELC and strong vs eventual consistency.
Microservices on day one
Nine services for three requirements, and a saga for what could be one transaction. Martin Fowler notes that almost every system he has heard of that was built as microservices from scratch “has ended up in serious trouble”.
Costs: solution design, and time. Repair: start with a few services along obvious seams, and say what would justify a split: separate ownership, or a different scaling profile. See monolith vs microservices.
Deep-dive mistakes
Deep dives carry most of the evidence for depth and failure handling, so mistakes here cost the most per minute.
Breadth without depth
Minute 35: twelve boxes, none explained down to its keys, data structures or behaviour at the peak.
Costs: depth, left blank; the classic route to a down-level. Repair: stop adding boxes. Name the hardest part and go two levels down: data model, key, algorithm, behaviour at the peak and when a node dies.
Options without a decision
“We could poll, long-poll, use SSE or WebSockets; each has pros and cons,” and then the next topic. Meta’s guide wants to see “how you think through basic tradeoffs”; one you never resolve shows no judgement.
Costs: depth and trade-offs. Repair: end each comparison with a decision, its price and its trigger: “SSE, because clients only listen; it costs a connection per viewer; I’d switch if they start sending.”
Defending a choice a number has ruled out
“Now assume ten times the traffic,” and the candidate insists the design still works “with more nodes”. Atlassian adds new trade-offs mid-round to “see how you adjust your thinking”, as part of assessing learning agility.
Costs: communication (Meta scores how you “address feedback”) and depth. Repair: change your mind out loud, citing the number. Amazon’s leadership principles praise people who work to “disconfirm their beliefs”.
Happy path only
Every flow works if every box is up: no timeouts, retries or duplicates, and nothing on what users see when a payment callback never arrives. Meta asks, “How are you mitigating potential risks and failure points?”
Costs: scale and failure, left blank. Repair: add one failure to every deep dive: what breaks, what users see, how it recovers. See idempotency and timeouts, retries and backoff.
“We’ll just shard it”
The hard part waved away in four words, so the next question, “by what key?” or “what about the hot key?”, gets no answer.
Costs: depth, as a red flag. Repair: each phrase needs its how: a shard key, its reason and a hot-key plan (database sharding); a cache key, TTL and invalidation rule (hot keys and cache stampedes); a queue’s partition key, lag alarm and dead-letter queue.
Communication and time mistakes
These are scored all round, and they decide whether the interviewer can see the rest of your evidence.
Thinking in private
A 40-second silence while you weigh options, or a ten-minute monologue with no check-in. Either way nothing reaches the notes, and nobody can steer you.
Costs: communication, plus every signal whose reasoning stayed in your head. Repair: narrate forks (“two options for ID generation; give me 20 seconds”) and announce each phase change, so the interviewer can redirect you.
Fighting or missing the steer
“What if the restaurant goes offline after accepting?” gets “we’ll come to that”, or a debate about realism. Amazon’s development manager ends his video by telling candidates to “listen to your interviewer”.
Costs: communication and problem navigation. Repair: treat each question as a pointer: answer briefly, then decide aloud whether to go deeper now. If you disagree, say so once, with a number, then commit; Amazon calls it “disagree and commit”.
Reciting a memorised design
Asked for auto-rickshaw dispatch in one city with 3,000 drivers, you deliver global, multi-region ride-hailing. At one ping every 5 seconds, those drivers send 3,000 ÷ 5 = 600 writes a second. Atlassian wants a “practical, not theoretical, conversation”.
Costs: problem navigation and communication. Repair: reuse parts, never the whole, and anchor each to this prompt: “The usual answer is a geospatial index; at 600 writes a second, one Redis node is plenty.”
Running out the clock
Minute 43, midway through the first deep dive, no wrap-up, and a board of arrows over erased boxes. Microsoft’s tips stress managing time “given the short 45-minute interview round”.
Costs: communication and solution design. Repair: check the clock at 15, 25 and 35 minutes, and start the wrap-up by minute 40 wherever you are: the bottleneck, the failure you’d watch, the next step.
What ends up in the notes
These notes are illustrative
No company publishes its interviewers’ notes. These lines are plausible paraphrases, showing how each mistake reads to someone who wasn’t in the room.
| Mistake | What the notes might say | Signal | Repair |
|---|---|---|---|
| Drawing before asking | “Drew at minute 1; requirements came only when prompted.” | Problem navigation | Questions and a written corner first |
| Adjectives, no numbers | “‘Scalable’ never defined; no quantitative requirements.” | Problem navigation | Propose numbers; ask if 10× off |
| Buzzword stacking | “Named Kafka; couldn’t say what it buffers or why.” | Solution design | Every box earns a requirement |
| Boxes nobody traced | “Create flow never walked through; unclear where codes come from.” | Solution design | Trace each requirement aloud |
| SPOF unnoticed | “Single ID allocator; failover raised by me.” | Scale and failure | Name it first, with user impact |
| Defended a ruled-out choice | “Kept ‘collisions are rare’ after the arithmetic was shown.” | Communication | Revise out loud with the number |
| Breadth without depth | “Broad and shallow; nothing below box level.” | Depth and trade-offs | One deep dive, two levels down |
| No wrap-up | “Ran out of time mid-dive; no bottlenecks or next steps.” | Communication | Wrap-up by minute 40 |
Read the middle column as a hiring committee would. “Raised by me” and “when prompted” tip a borderline round to a no: the interviewer did the work the rubric credits you for.
The mistake that sinks each level
The prompt is often the same at every level; the mistake that costs you the level isn’t. Meta’s guide says “it will be up to you to drive the conversation”, and the driving expected rises with level.
| Level | Level-sinking mistake | What it looks like | Repair |
|---|---|---|---|
| Mid-level | Over-engineering | Multi-region, event sourcing and eight services for 35 writes a second | The simplest design that meets the numbers; say what you’d add at 10× |
| Senior | Waiting to be led | Finishes the diagram, then asks where to go; failure only when asked | Choose the deep dives, hardest first; volunteer failures |
| Staff and above | A polished design with no future | Nothing on rollout, migration, cost, ownership or year two | A thread on phasing, cost, operations and reversibility |
Two replays of one round
The prompt: “Design a URL shortener.” Same candidate, same knowledge, two outcomes. The candidate proposes 1 million new links a day, 100 redirects per link and five years of retention:
- Writes: 10⁶ ÷ 86,400 ≈ 12 a second, about 35 at a 3× peak.
- Redirects: 100 × 12 = 1,200 a second, about 3,600 at peak.
- Storage: 10⁶ × 365 × 5 ≈ 1.8 billion links × 500 bytes ≈ 900 GB, or 2.7 TB with three copies.
| Moment | Sinking round | Recovered round |
|---|---|---|
| Minutes 0–5 | Recites the standard design: gateway, Kafka, Cassandra, Redis, Spark, Kubernetes. Asks nothing. | Starts the same way, stops at minute 2: “I’m drawing before asking.” Asks about volume, aliases, expiry and analytics. |
| Numbers | Ten minutes on storage, with 500 bytes typed as 500 KB: “about a petabyte, so Cassandra.” 1,000× off. | Three lines: 35 writes a second, 3,600 redirects, about 1 TB. “One primary, replicas, a cache; no Kafka.” |
| Design | No traced request. Codes from “hash the URL, keep 7 characters”. | Traces the redirect. Proposes the same hashing idea. |
| Minute 26 probe | “What if two URLs get the same code?” “Astronomically rare.” Holds that when pressed. | Does the arithmetic below, says hashing was wrong, switches to ID ranges per server. |
| Last 5 minutes | Still adding analytics. No wrap-up. | Wrap-up: hot links, allocator failure, abuse detection next. |
| Likely notes | “Recited a design; estimate 1,000× off; dismissed collisions.” | “Self-corrected twice using numbers; drove the round.” |
The arithmetic behind the second repair: seven base62 characters give 62⁷ ≈ 3.5 × 10¹² codes. By year five, with 1.8 billion taken, a fresh hash collides with probability 1.8 × 10⁹ ÷ 3.5 × 10¹² ≈ 1 in 2,000: at a million new links a day, about 500 collisions a day. By the birthday bound, the first is likely after only about 2 million links, two days in. Design a URL shortener has the full treatment.
Two repairs changed the outcome: one question at minute 2 and one revision at minute 26. Neither needed more knowledge.
Recovering mid-round
Almost every mistake here can be repaired in under a minute, and a repair you make yourself shows the habit interviewers hire for: noticing a design is wrong before it ships. Amazon’s leadership principles ask people to be “vocally self-critical”, and the SRE Workbook treats designs that pass most checks “only to flounder later” as an ordinary part of the process.
In the interview
Name the flaw before the interviewer does. The same single database reads as judgement when you say “this is my single point of failure; here’s the fix”, and as a gap when they have to ask.
| When you notice… | Say something like |
|---|---|
| You drew before asking | “Let me step back for two minutes and pin down what we’re building.” |
| No numbers | “Let me put a number on ‘fast’: search p95 under 300 ms. Tell me if that’s off.” |
| Arithmetic that decides nothing | “I’ll stop; whichever way this lands, it’s one database.” |
| A unit slip | “That’s bytes, not bits: 8 Gbps, not 1. That changes the cache plan.” |
| A box you can’t justify | “I added Kafka without a reason. At 35 writes a second I don’t need it.” |
| A number breaks your design | “That number breaks my plan. I’m replacing hashing with ID ranges.” |
| You’re behind | “Minute 30, no deep dive yet. I’ll take ID generation now and leave analytics.” |
Don’t over-correct
One acknowledgement is enough. Apologising repeatedly, or redrawing the board after one flaw, burns minutes and suggests you can’t tell a local fix from a rewrite.
A self-review scorecard for mock interviews
After each mock, score each check 2 for clear evidence, 1 for partial, 0 for missing. It’s a mirror for this page, not any company’s rubric. Work on your two lowest scores next time.
| Check | Clear evidence looks like | If 0, reread |
|---|---|---|
| Requirements | 3–5 “users can…” lines, two numbers and an out-of-scope list by minute 8 | Scoping mistakes |
| Estimates | Each number named its decision; units on every line; peaks, not averages | Estimation mistakes |
| Traced flows | Every functional requirement walked through aloud | Boxes nobody traced |
| Justified boxes | Each component tied to a requirement or number | Buzzword stacking |
| Failure | Single points of failure named before you were asked | The SPOF you drew; happy path only |
| Deep dives | Two or more, each ending in a decision and a metric | Breadth without depth; options without a decision |
| Revision | You changed course when a number or hint said so | Defending a ruled-out choice |
| Talk | No silence over 30 seconds; a check-in at each phase | Thinking in private |
| Clock | Wrap-up started by minute 40 | Running out the clock |
Record one mock in three
Watch it back with this table open. Most people find two things they missed live: silences far longer than they felt, and arrows drawn without a word of explanation.
Cheat sheet
| Remember | As |
|---|---|
| Why rounds are lost | No evidence for a signal, or evidence against it; rarely a knowledge gap |
| When the bill arrives | Mistakes made in minutes 0–24 usually cost you in minutes 24–45 |
| Scoping | Questions before boxes; numbers, not adjectives; say what’s out; reread the corner |
| Estimation | Name the decision first; units on every line; size for the peak |
| High-level design | Every box earns a requirement or a number; trace each flow; name the SPOF |
| Deep dives | Two finished beat four started; decision, price, trigger |
| Communication | Think aloud; questions are pointers; disagree once, then commit |
| Time | Check at minutes 15, 25 and 35; wrap up by 40 |
| Recovery | Notice, name, fix, continue, in under a minute |
| By level | Mid: don’t over-build · Senior: don’t wait · Staff: cover evolution and cost |
How to say it in the interview
Nobody asks you about mistakes directly; you show the repairs. Here is a recovery in the URL-shortener round:
“Before I go on, a correction. I said we’d hash the URL and keep seven characters. With 1.8 billion links over five years, a new hash would collide about once in 2,000 creates, roughly 500 times a day, so ‘rare’ was wrong. I’m switching to ID ranges: each server reserves a block of IDs from a small, strongly consistent counter and hands them out locally. That counter is now a single point of failure, so it lives in a replicated store, and a server that can’t reach it finishes its current block. I’m at minute 30, so I’ll finish the redirect cache and leave analytics for the wrap-up.”
What if I realise halfway that my design is wrong? Say so straight away, with the number or requirement that broke it, and replace only the part it rules out. Designs are expected to change; what’s scored is whether you noticed and how cleanly you fixed it.
What if I blank on a technology? Describe the property you need instead of the product: “a durable, partitioned log where consumers track their own offsets”. Then reason from that. Not knowing is cheap; bluffing a feature you’ll be asked to design is not.
What if the interviewer seems unhappy? Read their questions, not their face. An interruption usually means “more detail here”. If follow-ups suddenly get easier, you may be off track (Atlassian’s questions “ladder” both ways): reread the requirements corner, then offer a direction rather than asking for one.
How do I avoid sounding rehearsed? Rehearse moves, not answers. The opening questions, estimate format and deep-dive shape should be automatic; the content should come from this prompt’s numbers.
Can one mistake fail the round? Rarely, if you catch it. Rubric-based scoring weighs evidence across the whole round, so a corrected slip costs little. Patterns sink rounds: a signal left blank throughout, or a red flag you defend after it’s pointed out.
Where to go next
- How a system design interview works: the signals and level expectations behind this page.
- The delivery framework: the method and checkpoints that prevent most of these mistakes.
- Back-of-envelope estimation: estimates that pick boxes.
- Numbers to know: the thresholds that expose a 10× slip.
- Ten principles senior engineers design by: habits that make the senior and staff repairs automatic.
- Single point of failure: finding the box that takes everything down.
- Design a URL shortener: the full problem behind the replays.
- Contention and double booking: the hard part behind every “never double-book” rule.
References and further reading
- Preparing for your Full Loop Interview at Meta (Software Engineer Full Loop Interview Guide, PDF)metacareers.comThe design interview’s four focus areas, “up to you to drive the conversation”, trade-offs over optimal solutions, addressing feedback, and “it’s ok if you don’t know”.
- System Design Interview Prep, video transcript (Amazon Jobs)static.jobs.production.amazon-jobs.brightspot.cloudAn Amazon development manager on not jumping into the solution, requirements gathered but not used, and listening for the interviewer’s guidance.
- Prep Series, Senior Software Development Engineer, video transcript (Amazon Jobs)static.jobs.production.amazon-jobs.brightspot.cloudMistakes a senior interviewer sees: forgetting availability, claiming features you can’t design, and requirements left uncovered by the architecture.
- Leadership Principles (Amazon Jobs)amazon.jobsBeing “vocally self-critical”, working to “disconfirm their beliefs”, and disagree-and-commit: the behaviours behind revising a design gracefully.
- Engineering interview process (Atlassian Careers)atlassian.comA “practical, not theoretical” design session whose follow-ups “ladder” and add new trade-offs to test learning agility.
- Technical interviews (Microsoft Careers)careers.microsoft.comAsk clarifying questions, make a plan before building, and manage time in a 45-minute round.
- A guide to structured interviewing for better hiring practices (Google re:Work)rework.withgoogle.comComprehensive written feedback, poor-to-outstanding rubrics, judging the thought process, and confirmation bias as the reason structure exists.
- Introducing Non-Abstract Large System Design (Google SRE Workbook, chapter 12)sre.google“What happens when this component fails?”, starting again when a design flounders, and reasoning over final values.
- MonolithFirst (Martin Fowler)martinfowler.comWhy systems built as microservices from scratch so often end up in trouble, and the premium microservices charge.
- New Tweets per second record, and how! (Twitter Engineering, 2013, archived)web.archive.orgA one-second peak of 143,199 tweets against an average of about 5,700 a second: roughly 25× steady state.