Common Mistakes to Avoid
The top mistakes that fail candidates: diving into details too early, ignoring non-functional requirements, not discussing trade-offs, and over-engineering.
Why Good Engineers Fail System Design Interviews
System design interviews are not a pure knowledge test. Many experienced engineers who build excellent production systems struggle with these interviews because the format rewards a specific set of communication and judgment behaviors that do not always come naturally. Understanding the failure modes in advance is the highest-leverage preparation you can do.
Interview Tip
Record yourself doing a mock interview. Watch it back with the sound off first — are you drawing continuously? Are you looking at your diagram instead of the interviewer? Then watch with sound — do you state trade-offs, or just state decisions? Most candidates are shocked by what they see.
Mistake 1: Diving Into Details Too Early
The Premature Optimization Trap
Jumping into database schema, specific algorithms, or implementation details before agreeing on requirements is the most common fatal mistake. The interviewer does not know yet whether you understand the problem — and neither do you.
This mistake often looks like a candidate who hears "Design a URL shortener" and immediately says "I'll use base62 encoding with a 7-character hash, and here's the collision resolution algorithm..." They are designing a solution to a problem they haven't confirmed yet. What if the interviewer wanted to focus on analytics? Or multi-tenancy? The design might be completely wrong.
| Mistake Pattern | What the Interviewer Sees | Fix |
|---|---|---|
| Immediately starts coding a hash function | Cannot distinguish important from unimportant; no judgment | Always spend 5 minutes on requirements before any design |
| Deep-dives on database indexing in minute 3 | Cannot prioritize; will get lost in details in production | Complete breadth pass first; return to details later |
| Designs the logging system before the core feature | Focuses on supporting concerns before primary concern | Explicitly mark supporting systems as 'out of scope for now' |
Mistake 2: Ignoring Non-Functional Requirements
Non-functional requirements (NFRs) — availability, latency, consistency, durability, scalability — are not an afterthought. They are the requirements that determine which of several correct architectures you should actually build. A design that meets functional requirements but ignores NFRs is incomplete.
A candidate who designs a Twitter-like system with synchronous writes to a single relational database has met the functional requirements. But they have ignored the NFR of 10M daily active users and 99.9% availability. The design will fail in production. An interviewer looking for senior-level judgment will penalize this heavily.
- Availability: What is the target uptime? 99.9% allows 8.7 hours/year downtime. 99.99% allows 52 minutes.
- Latency: What is the p99 read latency target? This determines whether you need a cache layer.
- Consistency: Can users see stale data? This affects whether you choose eventual or strong consistency.
- Durability: Can you lose any data? This affects your backup and replication strategy.
- Throughput: What is the peak QPS? This drives your horizontal scaling and sharding strategy.
Interview Tip
Always write your NFRs on the whiteboard/diagram during the requirements phase. Leave them visible throughout the interview. Refer back to them when making decisions: "This choice of Cassandra satisfies our NFR of high write throughput while accepting eventual consistency, which we confirmed is acceptable."
Mistake 3: Stating Decisions Without Trade-offs
Every design decision has consequences. Candidates who say "I'll use Redis" without explaining why — or what they are giving up — are not demonstrating engineering judgment. They might as well be reading a list of buzzwords.
The Trade-off Formula
Use this formula for every significant decision: "I'll use [TECHNOLOGY/APPROACH] because [REASON SPECIFIC TO THIS PROBLEM]. The trade-off is [DOWNSIDE], which is acceptable because [JUSTIFICATION]." Example: "I'll use Kafka for the event stream because we need durable, ordered, replayable messages for the audit log. The trade-off is operational complexity and higher infrastructure cost, which is justified for a financial system where auditability is a hard requirement."
Mistake 4: Over-Engineering
Over-engineering is adding complexity that the requirements do not justify. A URL shortener for 1,000 users does not need a distributed caching layer with consistent hashing. Proposing one anyway signals that you do not understand how to match solution complexity to problem complexity — a critical engineering judgment skill.
Over-engineering often appears as: premature sharding, unnecessary microservices decomposition, complex consensus algorithms for problems that fit on a single node, or exotic data structures when a hash map would suffice. These choices also suggest the candidate learned patterns without understanding when to apply them.
Start Simple, Add Complexity Explicitly
Start with the simplest architecture that meets the requirements, then evolve it. Say: "The simplest version here is a monolith with a single Postgres database. Given our 10M DAU requirement, we'll need to scale out — let me show you how I'd evolve this." This demonstrates progressive thinking, not just pattern recall.
Mistake 5: Ignoring the Interviewer
Some candidates become so absorbed in their design that they stop reading the room. They miss the interviewer's body language, do not respond to subtle redirections, and barrel through planned content even when the interviewer is clearly uninterested in that area. This is a collaboration failure.
- Watch for the interviewer leaning forward — they are engaged with what you are saying, go deeper.
- Watch for the interviewer glancing at the time or their notes — they may feel you are spending too long in one area.
- If the interviewer starts asking about a specific component, that is where they want you to go.
- If the interviewer is silent, they may be waiting for you to move forward — transition explicitly.
Mistake 6: Treating the Whiteboard Like Scratch Paper
Your diagram is a communication artifact. A messy, unlabeled, cramped diagram — even if the underlying design is correct — makes it hard for the interviewer to follow your reasoning. Label every component, every connection, and every data store. Use clear spatial organization: clients on the left, databases on the right, queues in the middle.
Interview Tip
Before you draw any box, briefly narrate what you are about to draw and why. "I'm going to add a CDN here to cache static assets — this addresses our global low-latency requirement." Drawing first and explaining later means the interviewer does not know what they are looking at until you get back to it.