How Candidates Actually Lose

1. Designing before scoping

The most common and most costly. The prompt is "design Twitter", and thirty seconds later there are boxes on the board.

You have now committed to assumptions nobody agreed to, and the interviewer must either let you build the wrong thing or interrupt you. Both are bad.

Fix: five minutes of requirements, written down, before a single component. Explicitly park what you're excluding.

2. Designing for a scale nobody asked for

The reflex to architect for a billion users. It produces Kafka, six microservices, and a multi-region active-active topology for a product with 40,000 users.

This reads as pattern-matching rather than engineering, and at a scale-up it reads as someone who will burn the budget.

Fix: ask for the scale, estimate it, and let the number decide. Saying "this fits on one Postgres instance, and here's what would change my mind" is a strong answer, not a weak one.

3. No numbers

Everything is qualitative — "a lot of traffic", "we'd need many servers", "that could get big". Without numbers there is no way to distinguish a good choice from a plausible-sounding one, and the interviewer cannot give you credit for judgement you never demonstrated.

Fix: one estimate, early, out loud, rounded. Then use it in at least two later decisions.

4. Never discussing failure

The design assumes every component is up. Nobody mentions what happens when the cache is cold, the leader dies mid-write, or the region goes away.

This is the single clearest separator between mid and senior. Junior candidates design happy paths; senior candidates design failure paths and mention them unprompted.

Fix: every time you draw a box, spend one sentence on what happens when it's gone. See failure models.

5. Silent thinking

Thirty seconds of silence feels like five seconds to you and five minutes to the interviewer, who cannot grade an empty room.

Fix: narrate. "I'm weighing whether to partition by user or by time — let me think about the read pattern." Thinking out loud is not a weakness on display; it's the entire artefact being assessed.

6. Listing options without choosing

"We could use Kafka, or RabbitMQ, or SQS, or Redis streams…" and then moving on. This looks like breadth. It reads as an inability to commit.

Fix: name the options in one sentence, pick one, justify it in one more, and say what you gave up. "Kafka — I want the retained log for replay, and I'll accept the operational weight."

7. Tradeoffs only when pushed

You mention a technique's cost only after being asked "and what's the downside?" That timing tells the interviewer you knew it on demand, not that you think that way.

Fix: name the cost in the same breath as the choice. This one habit changes how a whole round reads.

8. Ignoring the hint

The interviewer says "what about a user with ten million followers?" and the candidate says "yes, we'd handle that with the same fan-out" and continues.

A hint is not conversation. It is a rescue attempt, and declining it is expensive.

Fix: treat any question about a specific scenario as a flashing light. Stop, engage with it, adjust the design visibly.

9. Arguing

Occasionally an interviewer will be wrong, or will phrase something imprecisely. Fighting it is a losing move regardless of who is right.

Fix: "That's fair — I was assuming X. If we instead assume Y, then I'd change this to…" You can hold your position on substance while conceding the frame. Disagreeing well is a positive signal; disagreeing rigidly is not.

10. Hand-waving the data model

"We'll store it in a database" — with no schema, no partition key, no index. The data model is where most real system design lives, and skipping it skips the assessment.

Fix: always write the key entities, the partition key, and the indexes the access patterns demand. Refer back to the read/write ratio you established in scoping.

11. Not knowing your own systems

The round drifts to "how does the service you described on your CV handle this?" and the answer is vague. Nothing damages credibility faster.

Fix: before any interview, be able to explain, for each system you claim: its scale in numbers, its data model, its failure modes, and one thing you'd change. This is worth an hour of preparation and it pays every round.

12. Treating it as an exam

Waiting to be asked questions, answering exactly what was asked, stopping. The interviewer ends up dragging the round forward, and the debrief says "needed a lot of prompting."

Fix: it's a collaboration in which you hold the pen. Check in — "does that direction seem useful, or would you rather I go deeper on the storage?" — then keep driving.

A pre-round checklist

Five things to have loaded before you start:

1. Latency numbers, well enough to estimate without stalling.
2. A default architecture you can draw in ninety seconds — LB, stateless app tier, primary with replicas, cache, queue, object store — as a starting point to adapt.
3. Your own three systems, with numbers, as in #11.
4. Two or three questions for them that reveal you think about operations: how do you deploy, what does on-call look like, what broke most recently.
5. The time budget from the framework, so the clock never surprises you.

What to take away

• Scope before designing; park what you're excluding out loud.
• Let the estimate size the system — including when it says "this is small".
• Name costs in the same breath as choices, and failure paths before being asked.
• Commit to one option; listing four is not breadth, it's avoidance.
• A hint is a rescue attempt. Take it visibly.
• Ten of the twelve failure modes are communication, not knowledge. Practise accordingly.