I’ve seen hundreds of system design interviews from both sides of the table. The pattern is always the same: candidates fail not because they lack technical knowledge, but because they fall into predictable, avoidable traps. The good news is that once you know what these traps look like, they’re easy to dodge.
This lesson covers the ten mistakes that most frequently kill system design interviews. For each one, I’ll show you what it looks like, explain why it tanks your score, and give you a concrete fix.
Mistake 1: Diving Into the Solution Without Understanding the Problem
What it looks like:
Interviewer: “Design a URL shortener.”
Candidate: “Great, so I’ll use a NoSQL database with a base62 encoding scheme, a load balancer in front, and Redis for caching…”
The candidate jumped straight into implementation without asking a single question. They assumed scope, scale, and requirements.
Why it hurts your score:
Interviewers evaluate whether you can define a problem, not just solve one. In the real world, the hardest part of engineering is figuring out what to build. If you skip requirements gathering, you signal that you’d build the wrong thing in production.
You also risk spending 35 minutes designing a system that doesn’t match what the interviewer had in mind. Then they ask “but what about X?” and you realize you designed for the wrong X.
How to fix it:
Spend the first 3-5 minutes asking clarifying questions. Not 20 minutes (that’s Mistake 9), but enough to establish:
- Who uses this? (B2B vs B2C, internal vs external)
- What are the core features? (Not everything, just the top 3)
- What’s the scale? (100 users or 100 million?)
- What are the non-functional priorities? (Latency? Availability? Consistency?)
A strong opening sounds like: “Before I start designing, let me make sure I understand the scope. Are we designing just the URL shortening, or also analytics and custom domains? What’s the expected scale in terms of URLs created per day and redirects per second?”
Mistake 2: Over-Engineering
What it looks like:
“For this chat application, I’ll use microservices with event sourcing, CQRS, a Kafka event bus, a separate read model, a GraphQL federation layer, and we’ll deploy it on Kubernetes with a service mesh…”
For a chat app. That maybe serves 10,000 users.
Why it hurts your score:
Over-engineering signals that you can’t prioritize. Interviewers are looking for engineers who solve the problem at hand, not engineers who architect a NASA mission for every CRUD app. It also suggests you’d burn months building infrastructure that nobody asked for.
Every component you add is a component you need to justify. If you can’t explain why you need event sourcing, you shouldn’t propose it.
How to fix it:
Start simple. Design the simplest system that meets the requirements, then add complexity only when the requirements demand it. If the interviewer says “now what if we need to scale to 10 million users?“, that’s when you add the cache layer, the read replicas, and the message queue.
A good heuristic: if you can’t explain in one sentence why a component exists, remove it.
Mistake 3: Under-Engineering
What it looks like:
“I’ll just use a single Postgres database, a single application server, and that should handle everything.”
Interviewer: “What if the server goes down?”
Candidate: “I guess we could restart it?”
Why it hurts your score:
Under-engineering shows that you haven’t internalized what it means to build production systems. Every real system needs to handle failures, scale beyond a single machine, and deal with concurrent access. If your design doesn’t acknowledge these realities, the interviewer worries you’d build something that falls over at the first sign of real traffic.
How to fix it:
You don’t need to design for Google scale from the start, but you do need to acknowledge that scale exists. Show that you’re thinking about:
- What happens when this machine fails?
- What happens when we 10x the traffic?
- Where are the bottlenecks?
- What’s the single point of failure?
“For the initial design, a single Postgres instance is fine. But I want to call out that for production, we’d need read replicas, connection pooling, and a failover strategy. Let me show how the design evolves when we need to handle more load…”
Mistake 4: Monologuing
What it looks like:
The candidate talks for 15 minutes straight. They draw boxes, explain every design decision, go on tangents about CAP theorem, and never once check whether the interviewer is following or interested in the direction they’re going.
Why it hurts your score:
A system design interview is a collaborative design session, not a lecture. The interviewer is your colleague, not your student. When you monologue, you miss signals. Maybe the interviewer was trying to steer you toward a specific deep dive. Maybe they think your database choice is wrong and wanted to discuss it. But you never gave them a chance.
Monologuing also suggests poor communication skills. In real design reviews, you need to read the room, invite feedback, and adjust.
How to fix it:
Check in every 2-3 minutes:
- “Does this high-level design make sense before I dive deeper?”
- “I could go deep on the caching layer or the database schema. Which would you prefer?”
- “I’m planning to use Kafka here. Does that align with what you had in mind?”
The interviewer’s reactions are information. Use them.
Mistake 5: Not Making Trade-offs Explicit
What it looks like:
“I’ll use DynamoDB for the database.”
Interviewer: “Why not a relational database?”
Candidate: “Uh… DynamoDB scales better?”
Why it hurts your score:
This is probably the single most important differentiator between mid-level and senior engineers in interviews. Every architectural decision is a trade-off. When you pick NoSQL over SQL, you’re trading query flexibility for horizontal scalability. When you add a cache, you’re trading consistency for latency. When you choose eventual consistency, you’re trading correctness for availability.
If you can’t articulate the trade-off, the interviewer assumes you don’t understand it.
How to fix it:
For every major decision, use the pattern: “I’m choosing X because Y, and I’m accepting the trade-off of Z.”
Examples:
- “I’m choosing DynamoDB because our access patterns are simple key-value lookups at high throughput. The trade-off is that we lose the ability to do ad-hoc joins, but our queries don’t need them.”
- “I’m adding a Redis cache in front of the database because reads outnumber writes 100:1. The trade-off is that users might see stale data for up to 60 seconds, which is acceptable for this use case.”
Mistake 6: Ignoring Non-Functional Requirements
What it looks like:
The candidate designs all the features (user can post, user can follow, user can like) but never discusses:
- How many users?
- What’s the latency target?
- What happens during a server failure?
- Is consistency or availability more important?
- How do we monitor this?
Why it hurts your score:
Anyone can draw boxes that implement features. What separates system design from application design is the non-functional dimension. The same “design a chat app” question has radically different answers depending on whether you’re building for 1,000 users (single server, WebSocket) or 1 billion users (globally distributed, eventual consistency, message fanout).
How to fix it:
After clarifying functional requirements, explicitly ask about non-functional ones:
- “What latency are we targeting for the critical path?”
- “Do we need strong consistency, or is eventual consistency acceptable?”
- “What’s our availability target? Five nines?”
- “How do we handle a datacenter failure?”
Then reference these throughout your design. “I’m using async writes here because our availability target of 99.99% is more important than immediate consistency for this feature.”
Mistake 7: Buzzword Bingo
What it looks like:
“We’ll use a microservices architecture with a Kubernetes orchestration layer, a Kafka event bus for event-driven communication, a Redis cache with write-behind strategy, a GraphQL API gateway, blockchain for audit trails, and serverless functions for background processing.”
When asked to explain any of these, the candidate gives a surface-level answer or says “it’s industry standard.”
Why it hurts your score:
Interviewers have a finely tuned detector for buzzword soup. If you name-drop technologies without understanding them, one follow-up question exposes it. “How does Kafka handle consumer group rebalancing?” or “What’s the write amplification trade-off with that Redis write-behind strategy?” and suddenly you’re stuttering.
It also suggests cargo-cult thinking: using technologies because other companies use them, not because the problem requires them.
How to fix it:
Only mention technologies you can explain at depth. For each technology:
- Explain what problem it solves in your design
- Explain why alternatives don’t work as well
- Be prepared for one level of follow-up questions
If you don’t know how Kafka partitioning works, say “message queue” instead of “Kafka.” It’s honest, and the interviewer will appreciate it.
Mistake 8: Not Knowing Your Components
What it looks like:
Candidate: “I’ll add a cache here to speed up reads.”
Interviewer: “How will you handle cache invalidation?”
Candidate: “…I’ll invalidate it when the data changes?”
Interviewer: “What if the cache invalidation fails? What if the write to the database succeeds but the cache delete fails?”
Candidate: ”…”
Why it hurts your score:
Adding a component without understanding its implications is worse than not adding it at all. Every component introduces failure modes, consistency challenges, and operational overhead. If you propose a cache, you need to understand cache-aside vs write-through vs write-behind patterns, TTL strategies, and the consistency implications of each.
How to fix it:
For the core building blocks (cache, queue, database, load balancer), understand at least:
- Cache: Invalidation strategies, consistency trade-offs, thundering herd, cache stampede
- Message Queue: At-least-once vs at-most-once vs exactly-once delivery, ordering guarantees, dead letter queues
- Database: Indexing strategies, partitioning schemes, replication lag, consistency models
- Load Balancer: Round-robin vs least-connections vs consistent hashing, health checks, session affinity
You don’t need to be an expert on all of them. But if you put a component in your design, you need to know enough to defend it.
Mistake 9: Poor Time Management
This is the silent killer. You don’t realize it’s happening until it’s too late.
What bad time management looks like:
- Spending 20 minutes on requirements (analysis paralysis)
- Spending 25 minutes on high-level design and running out of time before deep dives
- Getting stuck in a rabbit hole on one component while ignoring the rest
- Not leaving time to discuss trade-offs and extensions
Why it hurts your score:
The deep dive is where you score the most points. It’s where you show depth, handle edge cases, and demonstrate senior-level thinking. If you never get there because you spent too long on the high-level design, you’ve left your best material on the table.
How to fix it:
For a 40-minute interview, target this allocation:
| Phase | Time | What to Cover |
|---|---|---|
| Requirements | 5 min | Clarify scope, scale, priorities |
| High-Level Design | 10 min | Core components, data flow, API |
| Deep Dive | 20 min | 2-3 interesting components in detail |
| Wrap-Up | 5 min | Trade-offs, extensions, monitoring |
Practice with a timer. Literally set a 5-minute alarm for requirements. When it goes off, move to high-level design even if you’re not done clarifying. You can always revisit requirements later.
Mistake 10: Not Asking Clarifying Questions
What it looks like:
Interviewer: “Design a notification system.”
Candidate: “OK, so we need to support push notifications, email, SMS, in-app notifications, web push, Slack notifications, and WhatsApp integration…”
The candidate assumed the maximum scope and is now designing a system 5x more complex than what the interviewer intended.
Why it hurts your score:
Assuming scope instead of narrowing it means you either design too much (and do it shallowly) or design the wrong thing entirely. The interviewer had specific topics they wanted to explore, and you missed them because you never asked.
How to fix it:
Ask scope-narrowing questions early:
- “When you say notification system, are we focusing on push, email, and SMS? Or do we need to include in-app and Slack as well?”
- “Should I focus on the delivery pipeline, or also the notification creation and template management?”
- “Is this for a single product, or a platform that serves multiple products?”
Every question you ask narrows the design space, which means you can go deeper on what remains. Depth beats breadth in every interview.
The Meta-Pattern
Notice a pattern across all ten mistakes? They all boil down to three principles:
-
Communicate constantly. Check in with your interviewer. Make your reasoning visible. Ask questions.
-
Make trade-offs explicit. Every decision has a cost. Name it. Justify it. Show that you understand both sides.
-
Match complexity to requirements. Don’t over-engineer, don’t under-engineer. Let the requirements drive the design, not your desire to show off.
If you internalize these three principles, you’ll avoid most of the mistakes on this list. The technical knowledge matters, but it’s the behavioral layer that determines whether you pass or fail.
Self-Assessment Checklist
Before your next mock interview, review this checklist. After the interview, score yourself on each item:
| Behavior | Did I do this? |
|---|---|
| Asked 3-5 clarifying questions before designing | |
| Stated non-functional requirements explicitly | |
| Checked in with interviewer every 2-3 minutes | |
| Made trade-offs explicit for every major decision | |
| Spent < 5 minutes on requirements | |
| Spent > 15 minutes on deep dives | |
| Could explain every component I proposed | |
| Avoided naming technologies I can’t explain | |
| Left time for wrap-up and extensions | |
| Narrowed scope before expanding design |
If you can check all ten boxes, you’re in strong shape. Most candidates struggle with 3-4 of them. Focus your practice on the ones you miss most consistently.