Common mistakes and how to dodge them

Diving in before scoping

The most common mistake: hearing “design Instagram” and immediately drawing servers and databases. You skip requirements, skip estimates, and design the wrong system confidently. Always spend the first few minutes clarifying and scoping. It feels slow; it’s the highest-leverage time in the interview.

Treating it like a quiz with one answer

There’s no answer key. If you propose a design and defend it as the correct one, you’ve missed the point. The interviewer wants alternatives and trade-offs: “SQL gives me transactions here, but if writes dominate I’d move to a NoSQL store and give up cross-row transactions.” Show the fork, then choose.

Ignoring trade-offs

Every real decision costs something. Naming only the upside (“I’ll add a cache!”) reads as inexperience. Name the cost too: a cache adds an invalidation problem and a stale-read window. Maturity is visible in the but. (The whole of Chapter 3 is trade-offs for exactly this reason.)

Over-engineering

Reaching for Kafka, Kubernetes, and five microservices for a problem that a single database and a load balancer would solve is a red flag, not a green one. Start simple, then scale only where a number forces you to. “A single Postgres handles this load; I’d only shard once we pass ~X writes/sec” is a stronger statement than an unprompted distributed everything.

Hand-waving the hard parts

Saying “and then it scales” or “the cache handles it” when the interviewer is clearly probing a bottleneck signals you don’t actually know. If you’re unsure, reason out loud instead of asserting — narrate the options and pick one. A visible thought process beats a confident blank.

Going silent

System design is a conversation. Long silent stretches while you think leave the interviewer unable to follow or help. Narrate: “I’m weighing push vs pull for the timeline — let me think through the read load of each.” Thinking aloud lets them course-correct you early and is itself part of what’s graded.

Forgetting the non-happy path

Many candidates design only the sunny day. Strong ones bring up failure and scale unprompted: what happens when a node dies, a region goes down, traffic spikes 10×, or a queue backs up? You don’t need to solve them all — just show you see them.

A quick pre-flight checklist

• Did I clarify and scope the requirements?
• Did I estimate scale before designing?
• Did I state a trade-off for each major choice?
• Is this as simple as the requirements allow?
• Did I talk about bottlenecks and failures?
• Am I narrating, and checking in with the interviewer?