Common mistakes that sink design rounds
The common mistakes that fail system design interviews, from jumping to the solution and over-engineering to buzzwords without trade-offs and no failure handling, with what to do instead.
On this page
🚩 What sinks a design round?
Most failed design rounds don't fail on missing knowledge. They fail on a handful of habits: designing before knowing the problem, building for scale nobody asked for, naming tools without reasons, and losing control of the hour. Think of them like a driving test: people rarely fail because they can't steer, they fail for not checking the mirror.
For this lesson, we'll go through the eight mistakes I see most often from the interviewer's chair. For each one: what it looks like in the room, why it costs you, and what to do instead. They map closely onto the phases of the delivery framework, so if you follow that framework, you're already protected from most of them.
Below the line (out of scope)
- How the round is scored: How a system design interview works
- The maths, done briefly: Back-of-envelope estimation
The 30-second answer
The mistakes that sink rounds are about process more than knowledge. Candidates jump into boxes before agreeing on requirements, skip the non-functional numbers that should shape the design, or burn 15 minutes on estimates nobody uses. In the design itself, they over-engineer for scale that wasn't asked for, list technologies without trade-offs, and never ask what happens when something fails. Across the whole hour, they either wait to be led or go quiet while thinking. The fix for all of these is the same habit: say what you're doing, why, and what it costs.
What you’ll learn
- Recognise the eight habits that most often sink a design round
- Know why each one costs you, in terms of what the interviewer can and can't write down
- Replace buzzwords with the pattern fits because, costs, switch when
- Walk at least one failure scenario on purpose in your deep dives
- Run a quick self-check after every practice round
Where each mistake happens in the round
Try it yourself first
Before reading on, spot the mistakes in this opening. The prompt is "Design a news feed." The candidate says: "OK, so I'd use Kafka for the events, Cassandra for posts because it scales, Redis for caching, and a microservice per feature. Let me draw that." Then they draw silently for three minutes. How many of the eight mistakes can you find?
I count at least four: jumping to the solution, buzzwords without trade-offs, over-engineering (a microservice per feature before any requirement), and going silent.
01Mistakes in the first fifteen minutes
1. Jumping to the solution
What it looks like. The candidate hears "Design a chat app" and starts drawing WebSocket servers within 30 seconds. No questions about group size, history, delivery receipts or scale.
Why it hurts. You might design the wrong system. Worse, you give up the problem navigation signal entirely, because the interviewer never sees you scope a vague problem.
Do this instead. Spend about five minutes on requirements, even if you think you know the problem. Propose rather than interrogate: "I'll assume one-to-one and small groups up to 100 members, with message history. Is that right?" The delivery framework shows what to write down.
2. Ignoring non-functional requirements
What it looks like. The functional list is careful, then the candidate writes "scalable, highly available" and moves on.
Why it hurts. Non-functional requirements are what make a design interesting. A URL shortener without a read-latency target and a 100:1 read ratio is a CRUD app. Without numbers you can't justify a cache, a shard or a queue, so every component looks arbitrary.
Do this instead. Pick the two or three qualities that matter most for this product, attach a number to each ("p99 redirect under 100 ms", "99.99% available"), and say which wins when they conflict. Point back at them when you add components.
3. Spending 15 minutes on estimates
What it looks like. Careful multiplication of daily users, bytes per field and replication factors, down to "28,935 requests a second". Then the numbers are never mentioned again.
Why it hurts. It eats the time you needed for deep dives, which is where most of the senior signal lives. It also suggests you estimate out of ritual rather than for a reason.
Do this instead. Keep it under three minutes, round to one significant figure, and end every number with "so we need...". If no decision depends on the number, state your scale assumption in one sentence and move on. The estimation lesson covers when the maths is worth it.
Many candidates think the fix for mistake 3 is to skip estimates entirely. It isn't. Some decisions really do hinge on a number: whether data fits in memory, whether one database can take the writes, how long an ID must be. Skipping those makes your design look like guesswork. The skill is choosing which numbers to compute, not avoiding them.
02Mistakes in the design itself
4. Over-engineering
What it looks like. A system for 10,000 daily users with a service mesh, three databases, Kafka, a cache cluster and multi-region active-active replication. Every box is a technology the candidate has heard is "scalable".
Why it hurts. Each component adds failure modes, cost and operational load. An interviewer reads it as poor judgement: you can't tell when complexity pays for itself.
Do this instead. Start with the simplest design that meets every requirement, then add each component only when a requirement or number demands it, and say which one: "Reads are 100 times writes, so now I'll add a cache." Every box should have a reason you can say in one sentence.
5. Buzzword lists without trade-offs
What it looks like. "I'd use Cassandra because it scales." "Kafka for reliability." "Microservices for flexibility." Nothing explains why this tool fits this workload.
Why it hurts. Technical depth is scored on reasoning, not vocabulary. "Cassandra because it scales" tells the interviewer you know a name. It invites the follow-up you may not want: "What do you give up with Cassandra here?"
Do this instead. Use the pattern: option, why it fits, what it costs, when you'd switch. "Our access pattern is a write-heavy key lookup with no joins, so a wide-column store like Cassandra fits. We give up multi-row transactions, which we don't need. If we later needed rich queries, I'd add a search index fed from the same events." See Databases for system design interviews for the comparisons behind lines like that.
6. No failure handling
What it looks like. A clean happy-path design and a confident walkthrough. Then the interviewer asks "What happens if the cache cluster goes down?" and the candidate has no answer, or says "we'd add replicas" without explaining how traffic shifts.
Why it hurts. Production systems spend much of their life partly broken, and senior engineers are hired to design for that. A design that only works when everything is up is a mid-level answer at best.
Google's SRE book uses a simple example early in its chapter on cascading failures: two clusters share the load, and when cluster B fails, cluster A goes from 1,000 to 1,200 requests a second. A's frontends can't cope, start crashing or missing deadlines, and A ends up serving well under its original 1,000. The chapter names overload as the most common cause of cascading failures. A design with no overload plan can fail harder than the original fault.
Do this instead. In at least one deep dive, walk a failure on purpose: a node dies, a dependency slows down, traffic spikes 10 times. Say what the user sees and how the system recovers. Timeouts, retries with backoff and jitter, idempotency, rate limiting and graceful degradation are the usual tools. Backend failure modes goes deeper.
03Mistakes in how you run the room
7. Not driving the conversation
What it looks like. The candidate answers each question well, then stops and waits: "What should I do next?" The interviewer ends up running the structure.
Why it hurts. At senior level and above, driving is part of what's being measured. If the interviewer chose every deep dive, they can't write "identified the hard problems unprompted", and that line often decides the level.
Do this instead. Announce each transition and propose the next step: "That covers the high-level design. I think the riskiest part is the fan-out on write for celebrity accounts, so I'd like to go deep there. Sound good?"
8. Going silent
What it looks like. The candidate says "let me think" and then says nothing for two minutes while drawing, or stares at the board weighing options in their head.
Why it hurts. The interviewer can only score what they hear. Your best reasoning, done silently, never reaches the write-up. Silence also stops the interviewer from hinting before you go down a wrong path.
Do this instead. Think out loud, even when you're unsure: "I'm deciding between pushing posts to followers at write time and pulling at read time. Push makes reads cheap, but a user with 10 million followers makes one write cost 10 million. Let me go with push for normal users and come back to celebrities." If you truly need quiet, ask for it and set a limit: "Give me 30 seconds to sketch this."
04A quick self-check
Run this after every practice round.
| # | Question | If the answer is no |
|---|---|---|
| 1 | Did I agree on requirements before drawing? | Next time, open with "Let me spend 5 minutes on scope" |
| 2 | Does every non-functional requirement have a number? | Replace adjectives with targets |
| 3 | Did every estimate end in a decision? | Cut the ones that didn't |
| 4 | Can I justify every box in one sentence? | Remove the boxes you can't |
| 5 | Did I name a cost for every technology choice? | Practise "fits because, costs, switch when" |
| 6 | Did I walk at least one failure? | Add a failure to your deep-dive list |
| 7 | Did I choose the deep dives? | Propose them before you're asked |
| 8 | Was I quiet for more than 30 seconds? | Narrate, or ask for a timed pause |
05How to say it in the interview
You won't name these mistakes out loud in the round. What you can do is use phrases that make it obvious you're avoiding them.
In the interview
"Before drawing, I'd like five minutes on requirements so we design the right thing. I'll attach numbers to the important qualities, and only do maths where it changes a decision. I'll start with the simplest design that meets every requirement and add components only when a number calls for them, saying what each one costs. For deep dives, I'd suggest the read path and what happens when the cache fails. I'll think out loud as I go, so stop me if you'd rather I go somewhere else."
On the whiteboard
- Scope first: 5 min reqs before any box
- Non-functionals = numbers (p99, nines, QPS)
- Estimate → "so we need..." or skip it
- Simplest design first; every box has a reason
- Tool = fits because · costs · switch when
- Walk one failure: node dies, slow dep, 10x spike
- Propose the deep dives; narrate; no silent minutes
Further reading (4)
- Google SRE Book: Addressing Cascading Failures: Why a design without an overload plan fails worse than the original fault, with a worked two-cluster example.
- Google SRE Book: Handling Overload: Practical tools for the failure deep dive: load shedding, client-side throttling, sheddable requests and retry budgets.
- Google SRE Workbook: Introducing Non-Abstract Large System Design: Start simple, then ask whether it's feasible and resilient: the antidote to over-engineering.
- Martin Kleppmann, Designing Data-Intensive Applications (book site): Where to learn the trade-offs behind the tools, so you can explain a choice instead of naming it.