Module 01 · Lesson 05
Common mistakes that sink rounds
Ten ways strong candidates fail, the fix for each, and how to recover mid-round.
What you will be able to do
- Identify the ten recurring failure modes in a design round
- Replace each with a specific behaviour rather than a vague intention
- Recover a round after a mistake instead of abandoning it
- Use the end of the round to repair the weakest signal
The failure modes, in order of how often they appear
None of these are knowledge gaps. Every one of them happens to candidates who know the material and lose the room. Each entry is the wrong behaviour, then the behaviour that replaces it.
Instead
Starting to draw in the first minute
Do this
Spend five minutes on scope first, then draw. "Before I draw, let me check what this needs to do" costs nothing and prevents designing the wrong system.
Instead
Asking questions that do not change the design
Do this
Before asking, check whether either answer changes a component. "Should the UI be React or Vue?" is not a design question; "do users need to see their own write immediately?" is.
Instead
Skipping the numbers
Do this
Estimate the one axis that constrains the design and say it out loud. Without a scale you cannot justify any component choice, and every component becomes arbitrary.
Instead
Technology name-dropping without trade-offs
Do this
One option, one cost, one number. "Kafka" is not depth; "a partitioned log absorbs the write burst, and we accept that consumers can lag" is.
Instead
Designing only the happy path
Do this
Before the deep dives, ask "what happens when this piece dies or gets hot?" once per major component. That question is the deep dive list.
Instead
Going silent to think
Do this
Think out loud, even messily: "I am weighing a counter versus random codes — the counter avoids collisions but creates a bottleneck." Silence reads as nothing happening.
Instead
Treating pushback as an attack
Do this
Take the hint and go where it points. "Good point — at 50k writes a second a single primary struggles, so let me look at partitioning."
Instead
Refusing to pick an option
Do this
Choose, name the cost, and say when you would change your mind. "I would start with Postgres and revisit if write volume passes a few thousand a second."
Instead
Spending the depth budget on the easy part
Do this
Pick deep dives by risk. The login page is not where the system breaks; the fan-out, the hot key, or the consistency boundary is.
Instead
Ending with a summary and nothing else
Do this
Recap, then name the weakest part of your own design, then invite the interviewer's questions. Self-critique at the end repairs a lot of earlier damage.
The three that decide most rounds
If you fix only three, fix these: drawing too early, estimating nothing, and staying silent. Together they produce the classic failed round — a diagram of a system nobody scoped, justified by no numbers, narrated only at the end.
The silent deep dive
It feels productive: you are thinking hard about replication, and the answer is nearly there. From the other side of the call it is two minutes of nothing. Say the state you are in: "I am deciding whether the second replica can serve reads or only take failover — give me a second." That sentence keeps the round alive.
How to recover inside a round
Notice out loud, briefly
"I have been on scope for ten minutes — let me move to the design." Naming the drift converts a time-management failure into self-awareness, which is a positive signal.
Return to the framework, not to the beginning
You do not need to redo the work. Say where you are, what is still missing, and which phase it belongs to, then continue from there.
Repair the weak signal at the end
If navigation was weak but you built depth, the wrap-up can recover it: recap the scope you settled on, state what you deliberately left out, and ask the two questions you would have asked at the start.
Never argue about the premise
If the interviewer states a requirement you disagree with, adopt it and note the cost once. Winning the argument about whether the requirement is sensible loses the round about whether you can design.
Self-check before you start
- Do I have three opening sentences ready, or will I improvise them under pressure?
- Can I estimate requests per second from a user count in under 30 seconds?
- Do I know which two deep dives I would default to for a read-heavy system, and for a write-heavy one?
- What is my weakest signal, and what is the one behaviour that would raise it this round?
- What will I say in the last three minutes if the design is incomplete?
Q. I realised halfway through that I misread the prompt. What now?
Say it immediately and scope the correction: "I have been treating this as read-heavy, but if writes dominate then the earlier reasoning flips — let me redo the storage choice and keep the rest." Correcting early preserves most of the design. Correcting at minute 40 preserves nothing.
Q. Is it bad to say "I do not know"?
Only if it is the whole sentence. "I do not know how H3 compares to S2 at high latitude — could look it up; the property I need is a cell that neighbours cheaply, and both give me that" is a complete answer. Pretending to know is the only fatal version.
Worth remembering
- Most rounds are lost to one weak signal, not to missing technology. Find your weakest signal and fix that first.
- Drawing before scoping is the most common failure, and it is the easiest to avoid with one sentence.
- Silence is scored as absence. Narrating an uncertainty is always better than thinking quietly.
- A recognised mistake costs little if you name it and correct it. A hidden one costs the round.
Checkpoint
Answer all 3 questions to finish the lesson.
1. Which single behaviour most reliably prevents the classic failed round?
The revealed preference of a failed round is a diagram of an unscoped system. Five minutes of scoping makes every later decision traceable, which fixes design and navigation at once.
2. You have spent two minutes thinking about a replication choice and have not spoken. What should you do?
Communication is scored continuously and silence is scored as absence. Narrating the live decision shows the reasoning, which is what is being measured.
3. The interviewer asserts a requirement you think is unnecessary. Best response?
The round measures whether you can design under constraints, not whether the constraints are wise. Adopt, note the cost briefly, and spend your time on the design.