System design interviews have a high failure rate — not because the problems are impossible, but because candidates make predictable mistakes that signal junior thinking. After conducting hundreds of system design interviews, the patterns are clear. This guide covers the most common mistakes, what interviewers actually evaluate, and how to demonstrate the structured thinking that gets you hired.
Mistake 1: Jumping Into Design Without Requirements
The single most common mistake. The interviewer says “Design Twitter” and the candidate immediately draws boxes and databases. Problem: without clarifying requirements, you might design for 1000 users when the interviewer expects 100 million, or include features (DMs, trending) that are out of scope while missing the core feature (news feed). What to do instead: spend the first 5 minutes asking questions. “What are the core features?” “How many DAU?” “What is the read-to-write ratio?” “Do we need real-time updates?” “What latency is acceptable?” Write the agreed requirements on the whiteboard. Refer back to them throughout. This is not wasted time — it is the most important part. An interviewer who asks “Design a chat system” may want WebSocket architecture or may want message storage and delivery guarantees. You cannot know without asking. Signal to the interviewer: you understand that engineering is about solving the right problem, not just any problem.
Mistake 2: Over-Engineering for the Wrong Scale
Designing for Google scale when the requirements say 10,000 users. Adding Kafka, Redis, Elasticsearch, microservices, and Kubernetes for a system that would work fine with a single PostgreSQL instance and a monolith. This signals: you are pattern-matching from blog posts rather than thinking from first principles. The interviewer wants to see that you can match architecture complexity to actual requirements. A system handling 100 RPS does not need sharding. A system with 1 TB of data does not need a distributed database. Conversely: under-engineering for a system that needs scale is also a problem. If the interviewer says “100 million DAU,” a single database will not work. The key: do the back-of-envelope estimation first. Let the numbers guide your architecture. “Our estimation shows 120,000 reads per second. A single PostgreSQL instance handles 50,000. We need either read replicas or a caching layer.” This is data-driven design, not cargo-cult architecture.
Mistake 3: Monologuing Instead of Conversing
The interview is a conversation, not a presentation. Some candidates talk for 30 minutes without stopping, covering every possible aspect of the system. Problems: (1) The interviewer has specific areas they want to explore. If you never pause, they cannot steer the conversation. (2) You may spend 15 minutes on a component the interviewer considers trivial while skipping the one they care about. (3) It signals poor communication skills — in real engineering, you need to check alignment frequently. What to do: after covering the high-level design (10 minutes), pause and ask “I have ideas for the deep dive on the database design and the caching strategy. Which would you like to explore?” This shows confidence (you have opinions) and collaboration (you respect the interviewer priorities). During the deep dive, check in every 3-5 minutes: “Should I go deeper here or move on?” The best interviews feel like a collaborative design session between two senior engineers, not a lecture.
Mistake 4: Ignoring Tradeoffs
Stating “we use Kafka” without explaining why Kafka over RabbitMQ or SQS. Choosing “NoSQL” without discussing the tradeoffs versus SQL. Every design decision has tradeoffs, and stating them demonstrates engineering maturity. For every technology choice, briefly explain: why this over alternatives, what you gain, and what you sacrifice. “We use Cassandra for the message store because we need high write throughput and the access pattern is partition-key based (lookup by conversation_id). The tradeoff: no cross-partition joins, which means analytics queries must use a separate system.” If you cannot articulate the tradeoff, the interviewer assumes you are choosing by name recognition, not engineering judgment. Common tradeoff dimensions: consistency vs availability (CAP), latency vs throughput, cost vs performance, simplicity vs scalability, read optimization vs write optimization, and strong consistency vs eventual consistency. Mention at least 2-3 explicit tradeoffs during your design.
Mistake 5: Forgetting Failure Modes
Designing only the happy path. Production systems fail. The interviewer wants to know: what happens when the database goes down? When a service is slow? When the network partitions? For each critical component in your design, briefly address: “If the cache goes down, reads fall through to the database. Latency increases but the system remains functional.” “If the payment service is slow, we use a circuit breaker to fail fast and show the user a retry message.” “If the primary database fails, the read replica is promoted automatically (RDS Multi-AZ). RPO is near-zero with synchronous replication.” You do not need to design for every possible failure. Pick the 2-3 most critical components and explain their failure behavior. This demonstrates production awareness — you have operated real systems, not just designed them on whiteboards.
What Strong Candidates Do Differently
Patterns of senior candidates who pass: (1) They quantify everything — “P99 latency will be 50ms because reads hit the cache” not “the system will be fast.” (2) They draw clear diagrams — boxes with labels, arrows with protocols (HTTP, gRPC, Kafka), and data flow direction. The interviewer can follow the architecture visually. (3) They name specific technologies and explain why — “Redis for caching because we need sub-millisecond reads and support for sorted sets (for the leaderboard)” not “some cache.” (4) They proactively discuss monitoring — “We would alert on P99 latency, error rate, and cache hit ratio using Prometheus and Grafana.” This shows production mindset. (5) They manage time well — 5 minutes requirements, 5 minutes estimation, 10 minutes high-level, 15 minutes deep dive, 5 minutes wrap-up. They do not spend 20 minutes on requirements. (6) They say “I do not know” when appropriate — “I am not sure about the specifics of QUIC packet format, but I know it solves TCP head-of-line blocking.” Honesty builds trust; bluffing destroys it.