The six silent killers
Most candidates who fail system design don't fail because they "don't know Kafka." They fail because a few predictable habits eat the clock, hide risk, or make the interviewer lose trust.
Think of this post as a blooper reel. Once you've seen the gag, you can catch yourself mid-take and reshoot.
Cinematic universe when they asked for one scene.
Boxes without QPS, storage, or peak math.
Latency, consistency, availability left unsaid.
20 minutes on polish while the core path is blank.
One "perfect" choice — no alternatives named.
Silent drawing — interviewer can't read your mind.
Every pitfall below has a senior antidote. The difference is rarely more knowledge — it's a different instinct for the same prompt:
Why these six keep showing up: they are not knowledge gaps — they are judgment gaps. You can know Kafka cold and still burn 20 minutes on a song-sequence detail while the create path is blank. Interviewers are grading whether you can ship a coherent design under a clock, not whether you can recite every option. Treat this post as a pre-flight checklist you run in your head every five minutes.
Memorize the six names. Mid-interview, if you feel one arriving, say it aloud and course-correct — self-correction scores higher than silent perfection.
1. Overengineering
Trying to cover CDN, multi-region failover, ML ranking, billing, and admin dashboards in forty-five minutes is like planning a four-film cinematic universe when the producer asked for one tight second act.
What it looks like: You draw fifteen boxes before stating a single user flow. Every follow-up gets "we'll add a microservice for that." The whiteboard fills; the core path never ships.
Why interviewers hate it: It signals poor prioritization — the number one filter for senior levels. They can't tell if you can ship an MVP under constraints.
Why this trap is seductive: every follow-up feels like a chance to show breadth, so you keep adding boxes. The trade-off you are actually making is depth for spectacle — and depth on the riskiest hop is what senior rubrics reward. Interviewers probe next by asking "what's out of scope?" or "what ships in week one?" If you cannot answer in one sentence, you are already overscoped. Prefer a boring MVP that works end-to-end over a cinematic universe of half-drawn services.
How to recover mid-interview:
- Pause: "I'm overscoping — let me lock MVP in one sentence."
- Name your MVP before drawing another box.
- Explicitly list what's out of scope (analytics, admin, multi-region).
- Spend 60% of remaining time on the hardest hop — not the easiest box.
MVP first, phase-two list second, deep dive on the riskiest hop third. Complexity without a working core path is a failed delivery.
2. No numbers
Boxes without QPS, storage, or peak math are like a rally without a turnout estimate — you don't know if you need a maidan or a WhatsApp group.
It looks like: "We'll use Redis and Postgres" with zero sense of whether you need 100 QPS or 100k, sharding proposed before a single machine has shown any sign of struggling. Interviewers hate it because capacity estimates are the proof you can reason about scale — without them, every fancy component just looks like cargo cult.
Why numbers change the design: 200 QPS average does not need shards; 200k peak might. The same Redis box is either essential or premature depending on whether redirects are 100× creates. Trade-off: rough math is wrong by 2–5× and still useful; silence forces the interviewer to assume you cannot size anything. Expect the next probe to be "what breaks at 10×?" — if you never established baseline QPS, that question lands like a trap.
How to recover: Stop drawing. Ask two clarifying numbers. Do 60 seconds of napkin math out loud. Then justify each component against those numbers.
- QPS — average and peak (peak often 5–10×).
- Storage — records × size × retention × growth.
- Bandwidth — especially for media or fan-out.
- Read:write ratio — drives caching and replica choices.
No component without a number that justifies it. Rough math spoken aloud beats silent guessing every time.
3. Ignoring NFRs
Functional requirements get the airtime. Non-functional requirements — latency, consistency, availability, durability — get a vague wave. That's a manifesto without a budget.
What it looks like: You design a feed that "works" but never say whether stale data for 5 seconds is OK, or whether a region outage must stay within 99.9%. Tradeoffs live in NFRs, and skipping them means you can't defend consistency vs availability, or cache TTLs vs freshness.
Why NFRs are the spine of deep dives: every interesting follow-up is an NFR conflict in disguise. "Can the feed be a few seconds stale?" decides push vs pull urgency. "Must money never be wrong?" decides fail-closed vs fail-open. If you never wrote the NFRs down, your later answers sound random. Interviewers probe next by picking one NFR you skipped and forcing a tradeoff — so volunteer latency, consistency, availability, and durability in 60 seconds before you draw.
- Latency — p99 targets for the critical path (redirect < 100ms?).
- Consistency — read-your-writes? eventual OK for feeds?
- Availability — fail open vs fail closed on dependency loss.
- Durability — can we lose analytics events? Never lose money?
How to recover: After functional requirements, spend 60 seconds listing NFRs as bullets. Tie every later choice back to one of them.
Write NFRs next to functionals before you draw. Every deep-dive answer should point at an NFR you already named.
4. Rabbit holes
The most expensive box on your diagram is the one you added without a reason.
Twenty minutes on consistent hashing details while the create/read path is still a blank page. That's reshooting one song sequence while the climax hasn't been filmed.
What it looks like: The interviewer asks a mild follow-up; you vanish into implementation weeds. Time runs out. Feedback says "time management."
Why interviewers hate it: They need a working end-to-end story. Depth without breadth fails delivery. Depth after a working HLD is what they want.
Why rabbit holes feel productive: a mild follow-up sounds like interest, so you chase it. The trade-off is wall-clock — every minute on consistent hashing details is a minute not spent on the create/read path. Senior move: park explicitly, finish the spine, then ask which deep dive they care about. Interviewers often planted the follow-up as a test of time control, not as a demand for a 15-minute lecture. If they really want depth, they will say so after you park.
How to recover:
- Say: "Parking this — I'll return after HLD."
- Finish the critical user journey boxes.
- Ask which deep dive they care about most.
- Go deep only on the one they pick (or the riskiest one).
Breadth first, depth second. Explicitly park rabbit holes — interviewers respect time control more than encyclopedic asides.
5. No tradeoffs
One "perfect" choice with no alternatives named is a single-party ticket. Senior interviews are about choosing under constraint, not naming the trendy tool.
What it looks like: "We'll use Cassandra" with no comparison to Postgres + shards. Or fan-out on write with no mention of the celebrity problem.
Why interviewers hate it: Blind certainty looks junior. They want: option A, option B, why A for these requirements, what breaks at 10×.
Why "just use Cassandra" fails the rubric: tools are not designs. The senior signal is the decision frame — latency vs complexity vs consistency — applied to these requirements. Trade-off talk also inoculates you against gotchas: if you already named the celebrity problem as the failure mode of pure push, the follow-up feels like you invited it. Interviewers probe next with "why not the other option?" — so answer it before they ask: alternative, rejection reason, failure mode of your pick, what you'd switch at 10×.
- Always offer at least two options for ID generation, storage, or fan-out.
- State the winning criteria: latency, cost, complexity, consistency.
- Name the failure mode of your choice (hot keys, SPOF, stale reads).
- Say what you'd switch at 10× traffic.
How to recover: After stating a choice, add: "Alternative was X; I rejected it because Y." Instant senior signal.
Choice + alternative + reason + failure mode. Four beats. Practice them until they're automatic.
6. Weak communication
Drawing silently while the interviewer watches is like shooting without calling "Action" — nobody knows what scene you're in.
Long pauses, unexplained arrows, jargon without tying to a requirement — the interviewer has to guess your intent, and guessing rarely favors you. Communication is an explicit rubric theme: a mediocre design narrated well often beats a clever design narrated poorly.
Why silence is expensive: the interviewer cannot give partial credit for thoughts they never heard. Narration also lets them steer you — a 10-second check-in can save 15 minutes of wrong direction. Trade-off: talking while drawing feels slower, but it is faster than redrawing after a misunderstanding. Expect probes that start with "so you're saying…" — if they cannot paraphrase your design, communication failed even if the boxes were right.
- Label every box as you draw it — purpose in one phrase.
- Narrate the happy path end-to-end before deep dives.
- Check in: "Does this match what you want to explore?"
- When stuck, think out loud — silence is worse than a wrong turn.
How to recover: Zoom out verbally. Restate the user goal in one sentence. Then walk the path again, slowly, labeling each hop.
If the interviewer can't repeat your design back, you didn't communicate it. Narrate every box; check in every few minutes.
Recovery moves mid-interview
Made a mistake? Recover out loud. Interviewers reward self-correction more than perfection.
Try: "Actually — if writes are this heavy, a single primary won't hold. Let me add a write-ahead log and revisit the read path." That's senior energy.
- Name the pitfall: "I'm rabbit-holing — parking this."
- Reset scope: one-sentence MVP + out-of-scope list.
- Add the missing number or NFR in 30 seconds.
- Offer the alternative you skipped, then reaffirm the choice.
- Re-narrate the happy path so the interviewer is synced.
Why recovery scores so high: interviews are a simulation of real design reviews, where changing your mind with new constraints is normal. Silent stubbornness looks worse than a loud course-correct. Keep recoveries short — one sentence for the mistake, one for the fix, then re-narrate the happy path so the interviewer is synced again.
Self-correction is a feature, not a bug. Say the mistake, fix the design, move on — don't apologize for thirty seconds.
Cost and performance levers
Pitfall clinic with fixes
Recovery phrase
If you go down a rabbit hole: "Let me zoom out and revisit requirements — I may be over-optimizing." Interviewers respect course correction.
Failure modes to mention
Call out at least one dependency failure (DB down, cache stampede, queue lag, region outage) and your mitigation (timeouts, retries with jitter, degraded mode, circuit breaker).
Interview Q&A by level
Practice saying these out loud for common interview pitfalls. Interviewers grade clarity and judgment more than buzzwords.
Match depth to the bar: define → trade off → operate. Don't dump principal answers in an entry-level screen.