How candidates lose the interview
Name the eight failure modes that sink a design interview, and the exact sentence that repairs each one before the interviewer stops taking notes.
Most rejected candidates knew enough to pass. They lost on process: they drew boxes before they knew what they were building, or made eight architectural choices in forty-five minutes without attaching one number to any of them. Every failure below is recoverable inside the same interview, and each has a sentence that repairs it.
Designing before scoping
The interviewer says "design a ride-hailing service" and within thirty seconds there is a load balancer, three app servers and a database on the board. This is the most common way to lose, and the fastest to spot.
The cost is not a wrong design. It is that you have demonstrated the behaviour that produces a six-month project nobody asked for, so the interviewer stops evaluating your architecture and starts evaluating your judgment.
Spend five to seven minutes before the first box. Ask what the system does, then what it must survive: "Real-time matching only, or payments and ratings too? Thousands of rides a day or millions?" Then get an explicit yes: "So — real-time matching, one metro, 500k rides a day, payments out of scope. Correct?" See functional vs non-functional requirements.
No numbers, so nothing is falsifiable
"We'll add a cache" is not a decision. It carries no hit rate, no QPS and no failure behaviour, so nobody can agree or disagree with it. An unfalsifiable claim scores zero: it would have been said regardless of the requirements.
Do the arithmetic on the board:
- 10M DAU x 5 feed opens/day = 50M requests/day
- 50M / 86,400 s ~= 580 QPS average
- peak is typically 2-5x average; assume 3x ~= 1,700 QPS peak
- a feed cache at a 90% hit rate absorbs 1,530 of those, leaving ~170 QPS for Postgres
- ~170 QPS is about 3% of the ~5,000 simple QPS one commodity Postgres box handles
The cache is now falsifiable, and it survives being wrong: at a 50% hit rate, 850 QPS still fits on one box. Quote p99, not the mean: the mean hides the tail. Cache hit rates is where the 90% comes from.
Naming a technology instead of a property
"We'll use Kafka" earns nothing on its own. The interviewer has heard the word; they are listening for the property that made the pick correct, because that is what transfers to the next problem.
The repair is one clause longer:
- Weak: "We'll put the events in Kafka."
- Repaired: "We need a durable, replayable log: after a bad deploy the consumer re-reads the last 24 hours, and a queue that deletes on ack cannot. Kafka gives us replay; so does Pulsar."
- Weak: "Use Cassandra for the device data."
- Repaired: "We write ~50,000 events/second, always keyed by device id, and never query across devices. That is a wide-column store with a partition key we control. If we needed cross-device joins I would stay on Postgres."
Property first, product name last. If you cannot name the property, you have not made the choice yet. Message queues covers the guarantees behind this pick.
Over-engineering for scale nobody asked for
Sharding a database that serves 50 QPS. 50 QPS x 86,400 = 4.3M requests/day against roughly 5,000 simple QPS on one commodity box — about 1% of one machine, 100x of headroom. Sharding buys nothing and costs plenty: cross-shard joins stop working, multi-row transactions stop being atomic, resharding becomes a quarter of somebody's life.
Over-engineering is scored as badly as under-engineering, and for a worse reason. Under-engineering is a knowledge gap. Over-engineering is a judgment gap about cost and operability: it says you will spend the team's quarter on capacity nobody asked for and hand on-call five moving parts where one would do.
Full credit: "One Postgres box covers this at roughly 1% utilisation. I'll note where the shard key goes if we grow 100x — customer_id — but I am not building it today." Declining a technique you can name is the stronger signal. Database scaling has the thresholds.
Treating a hint as curiosity
"What happens if that node dies?" is not a question. It is a rescue: the interviewer has seen a single point of failure and is offering you the chance to fix it before they write it down. "It would fail over" wastes the rescue. Ignoring it reads as not listening.
Take it literally — blast radius with a number, then the fix: "Today that is a single point of failure. If it dies, all 1,700 QPS land on Postgres, about 34% of one box, so we stay up but p99 jumps. I'd run a follower with automatic failover and collapse duplicate misses into one origin read." Then stop and let them steer.
Going silent while thinking
Thirty seconds of silence reads as being stuck, and the interviewer has no way to help. You are scored on how you think, and an unnarrated thought is unscored.
Use this, verbatim: "Let me think for fifteen seconds — I'm weighing whether the counter lives in Redis or in the row itself." The pause is labelled, and a hint can land in it.
Presenting every choice as free
A design where nothing costs anything is a design nobody has operated. "We'll read from a follower to scale reads" is half a sentence.
The other half: replication lag breaks read-your-writes, so a user who posts a comment and refreshes watches it disappear. Pin that user's reads to the leader for a few seconds after the write. Say the cost in the same breath as the choice, not as a bullet at the end.
The same holds for CAP. It is not "pick two of three" — partitions are not optional. When a partition occurs you choose consistency or availability for its duration; PACELC covers the other 99.9% of the time, where the choice is Else, Latency or Consistency. Reading from a follower on a healthy network is that latency-over-consistency choice; naming it shows you hold consistency models rather than a slogan.
Running out of time because the deep dive sprawled
The clock fails in a predictable place: the high-level design expands into a forty-minute tour of the write path, and the interview ends before failure modes come up. An unfinished design scores as a missing design.
Timebox out loud and defer in public: "I'd also add a CDN on the media path and a dead-letter queue on the consumer, but let me finish the write path first." Deferring on the record earns the point for knowing the component; silent omission does not. Eight minutes from the end, cut yourself off: "I want to leave time for failure modes — can I close the write path here?"
In an interview
All eight test one thing: whether you are safe to hand an ambiguous problem and a budget. An interviewer forgives a wrong index choice and does not forgive a candidate who never asked what the system was for.
Say the numbers before the components, the property before the product name, and the cost in the same sentence as the choice. Narrate the pauses. Treat every question as a rescue, because it usually is.
The mistake that loses most points is the quiet one: a complete-looking design that answers a question nobody asked, with no arithmetic and no trade-off named. It fills the board and scores near zero, because none of it was a decision.
Check yourself
1. A candidate proposes sharding the orders table. The service takes 2M orders/day. Shard or not? Show the arithmetic.
2M / 86,400 ~= 23 QPS average, ~70 QPS at 3x peak — about 1.4% of the ~5,000 simple QPS one commodity Postgres box handles. Do not shard. Name the key (customer_id) and the trigger — sustained load past ~2,500 QPS — then move on.
2. The interviewer asks "what happens if that Redis node dies?" You have six minutes left. What do you say?
Treat it as a rescue: blast radius with a number, then the fix, then stop: "Today it is a single point of failure. On a cold cache all 1,700 peak QPS hit Postgres, roughly 34% of one box's ~5,000, so we stay up but p99 degrades. I'd add a follower with automatic failover and collapse duplicate misses."
3. Rewrite "we'll read from a follower to scale reads" so it names its trade-off.
"Reads go to a follower, which trails the leader by tens of milliseconds. That breaks read-your-writes: a user who posts and refreshes may not see their own post. I'd pin that user's reads to the leader for five seconds after a write. In PACELC terms, with no partition we choose latency over consistency; the pin buys it back for the one case users notice."