Common system design interview mistakes

The mistakes that cost candidates system design interviews and how to avoid them: skipping requirements, designing before estimating, buzzword architecture, ignoring the data model, no trade-offs, missing failure modes, poor time management and not driving the conversation.

Reading is half of it. See this used in a real interview: walk through Design a URL Shortener →

Most candidates who fail system design interviews know enough technology. They fail because of how they use the 45 minutes: they jump into boxes before agreeing on what to build, name technologies without reasons, or run out of time before the interesting part. The good news is that these mistakes are predictable and fixable with practice. Here are the most common ones, what interviewers conclude from them, and what to do instead.

1. Designing before clarifying

Mistake: hearing "design Twitter" and immediately drawing load balancers.

Why it hurts: you may solve the wrong problem, and you miss the signal interviewers want most at senior levels: scoping.

Instead: spend the first five minutes on functional requirements (the three or four core features), explicit non-goals, and non-functional requirements (scale, latency, consistency, availability). Write them down. See the interview framework.

2. No numbers

Mistake: designing without any estimate of traffic or data size, or doing ten minutes of arithmetic that changes nothing.

Instead: a few quick estimates that drive decisions: peak QPS, read/write ratio, storage per year, and the biggest single key or user. Then say what they imply ("3 TB a year fits on one database; 50,000 reads per second need caching"). See back-of-envelope estimation.

3. Buzzword architecture

Mistake: adding Kafka, Cassandra, Kubernetes, a service mesh and microservices to a problem that needs a database and a cache.

Why it hurts: it signals pattern matching rather than judgement.

Instead: start simple and add components only when a requirement or a number demands them, saying why each time: "we add a queue here because sending notifications is slow and must survive restarts."

4. Ignoring the data model

Mistake: boxes and arrows with no tables, keys or access patterns.

Instead: define the main entities, their keys, and how each core query is served. Choose the database from the access patterns, and state the partition key. Most hard problems (hot keys, consistency, pagination) only become visible here. See data modelling and denormalisation.

5. No API

Mistake: never stating what the client calls.

Instead: a few endpoints with key parameters and responses, including pagination and idempotency where relevant. It anchors the rest of the design. See API design.

6. No trade-offs

Mistake: presenting each choice as obviously right.

Instead: for important decisions, name the alternative and why you did not choose it: "fan-out on write for fast reads, at the cost of write amplification; celebrities use pull instead." Interviewers grade reasoning more than choices. See fan-out on write vs read.

7. Happy path only

Mistake: never discussing what fails.

Instead: after the core design, walk through failures: a server dies, the database primary fails, a dependency is slow, a message is delivered twice, traffic spikes 10x. Mention retries with idempotency, replication and failover, timeouts and load shedding. See rate limiting and resilience and delivery semantics.

8. Going deep too early, or never

Mistake: spending 20 minutes on the perfect ID generator before the high-level design exists, or staying at the box level for the whole interview.

Instead: complete a simple end-to-end design in about 15 minutes, then go deep on the two or three parts that matter most for this problem (the feed fan-out, the matching engine, the delivery guarantees), ideally the ones the interviewer steers toward.

9. Not driving

Mistake: waiting for the interviewer to ask questions, or asking "what should I do next?"

Instead: narrate a plan ("I'll cover requirements, estimates, API, data model, high-level design, then deep dives on X and Y") and lead through it, while checking in: "does that match what you had in mind, or should I focus elsewhere?" Interviewers' hints are signals; follow them.

10. Vague consistency claims

Mistake: "we'll use eventual consistency" for everything, or "strong consistency" without knowing the cost.

Instead: choose per feature, with mechanisms: read-your-writes for a user's own posts, transactions for payments, eventual for counters. See consistency models.

11. Forgetting operations

At senior levels, mention briefly how the system is monitored (key metrics and SLOs), deployed safely and scaled. A sentence or two is enough. See SLIs, SLOs and error budgets and deployment strategies.

12. Silence or monologue

Both hurt. Think out loud, but in structured chunks, and pause for reactions. If you need a moment, say so ("let me think about the hot partition case for a second").

How to practise

Practise out loud under time pressure, with someone (or something) asking follow-ups, and review afterwards against a checklist like this one. Start with classics such as Design a URL Shortener, Design a Rate Limiter, Design a News Feed and Design WhatsApp, and listen to how a full walkthrough flows before attempting it yourself.

Checklist

• Requirements and non-goals agreed in the first five minutes.
• A few estimates that change decisions.
• Simple first; every component justified.
• Data model, keys and API defined.
• Trade-offs named for major choices.
• Failure modes and operations covered.
• End-to-end design first, then focused deep dives; you drive, and you listen.