Courses › System Design › Getting Started

Common Mistakes

The habits that sink interviews — and what to do instead.

Most system design interviews aren't lost because the candidate didn't know a technology. They're lost to a handful of habits: poor time management, unexplained choices, and designs that are either too shallow or too complicated. Here are the mistakes interviewers see most often, and what to do instead.

1. Designing before agreeing on the requirements

What it looks like: "OK, so we'll have a load balancer, then some app servers…" in the first minute.

Why it hurts: you may solve the wrong problem, and you lose the chance to show you can scope one.

Instead: spend ~5 minutes on functional requirements (3–5 core features), explicit out-of-scope items, and the non-functional requirements that shape the design: scale, latency, consistency, availability. See the Delivery Framework.

2. Estimating without a conclusion

What it looks like: five minutes of arithmetic ending in "so that's about 2 petabytes."

Instead: estimate only when a number decides something, and always say what it means: "2 PB means images must live in object storage, not the database." See Back-of-the-Envelope Estimation.

3. Naming technologies without reasons

What it looks like: "We'll use Kafka, Cassandra and Redis" — with no explanation.

Why it hurts: it reads as buzzword matching, and it invites "why?" questions you may not be ready for.

Instead: tie every choice to a requirement. "Writes are 50k per second and access is always by user ID, so a wide-column store partitioned by user fits." See Choosing a Technology.

4. Over-engineering

What it looks like: sharding, multi-region active-active, and microservices for a system with 10k users.

Instead: start with the simplest design that meets the requirements and evolve it when a requirement demands it. Interviewers reward judgment — knowing when *not* to add complexity — as much as knowing how.

[!TIP] Simple first, then scale "One PostgreSQL primary handles this load. If we needed 10× more, I'd add read replicas first, then shard by user ID." This shows you know the scaling path without paying for it up front.

5. Staying shallow everywhere

What it looks like: a complete diagram after 20 minutes, then vague answers to every follow-up.

Instead: after the high-level design, pick the two or three hardest problems and go deep: data model and indexes, concurrency control, failure handling, the exact sequence of operations. Depth is where senior signals come from. See What Interviewers Look For.

6. Ignoring failure

What it looks like: a design that works perfectly as long as nothing crashes, times out or is retried.

Instead: for each critical path, ask: what if this component dies mid-request? What if this message is delivered twice? What if the dependency is slow? Mention idempotency, retries with backoff, and resilience patterns where they matter.

7. Hand-waving the data model

What it looks like: "We'll store it in a database."

Instead: name the key entities, the primary keys and the indexes that support your main queries. Many deep dives — contention, hot partitions, pagination — can't be answered without a concrete data model. See Data Modeling.

8. Saying "strong consistency" or "eventual consistency" for everything

Instead: choose per feature: bookings need strict correctness, like counts don't, a user's own posts need read-your-writes. See Consistency Models.

9. Not listening to the interviewer

What it looks like: pressing on with your plan after the interviewer hints at a problem, or arguing with a constraint they've set.

Instead: treat hints as gifts. "Good point — if that service is slow, requests will pile up here. Let me add a queue." The interviewer is telling you where the points are.

10. Running out of time

What it looks like: a perfect requirements section and API, then no time for the design's hardest parts.

Instead: keep a rough clock: requirements ~5 minutes, entities and API ~5, high-level design ~10–15, deep dives ~15–20. Get a working end-to-end design on the board before polishing anything.

11. Going silent

What it looks like: long pauses while you think, then a finished answer.

Instead: think out loud — the interviewer is grading your reasoning, not just the result. If you need a moment, say so: "Let me think about how to handle the hot key for a second."

[!INTERVIEW] Recovering from a mistake You will make mistakes. Catching and fixing one is a positive signal: "Actually, this has a race — two requests could both read the old balance. Let me make that update conditional." Interviewers remember the correction more than the error.