Most candidates who fail a system design interview know enough.
They know what a cache is. They can explain sharding. They have watched the YouTube design five times.
They still fail. Not because of what they know, but because of how they use it in 45 minutes.
Interviewers score a short list of signals. Can you scope an ambiguous problem? Can you make a choice and defend it? Can you find the weak spot in your own design? Can you run the conversation?
The seven mistakes below break those signals. Each one comes with a weak answer and a stronger one, so you can hear the difference.
1. Drawing boxes before asking questions
The prompt is "Design a news feed." The candidate grabs the marker and draws a load balancer.
This feels productive. It isn't. A news feed for 500 friends and a news feed for 50 million followers are different systems. You don't know which one you're building yet.
Weak: "Okay, so we'll have clients, a load balancer, and some app servers..."
Strong: "Before I draw anything, a few questions. Is this a friends feed or a follow feed with celebrities? Ranked or chronological? How fresh does it need to be? Roughly how many daily users?"
Think of it like a contractor. A good one asks how many people will live in the house before pouring the foundation.
Spend the first five minutes here. Write the answers on the board. You will point back at them later.
2. Doing the math, then ignoring it
Many candidates have learned to do back-of-the-envelope estimates. They compute 12,000 writes per second. Then they never mention that number again.
Estimates are not a ritual. They are evidence. Every number should change a decision.
Weak: "So that's about 12K writes per second. Okay, moving on to the API."
Strong: "12K writes per second is more than I'd want on one Postgres primary for this workload. So I'll partition by user ID from the start, and I'll keep the write path thin."
If a number doesn't change your design, you probably didn't need to calculate it.
3. Naming tools instead of making decisions
"We'll use Kafka." "Put Redis in front." "Use Cassandra because it scales."
Naming a tool is not a design decision. The interviewer wants to know what problem it solves and what it costs you.
Weak: "We'll put Kafka between the services."
Strong: "The upload path and the thumbnail path don't need to finish together. I'll put a queue between them so a slow thumbnail job can't block uploads. The cost is that thumbnails show up a few seconds late, which is fine here."
A simple test: for every component, say one sentence about why it's there and one sentence about what it costs. If you can't say the second sentence, you don't understand the choice yet.
4. Designing only the happy path
The design works perfectly as long as nothing breaks. In production, something is always broken.
Interviewers often ask, "What happens if this node dies?" Candidates who freeze on that question usually never thought about failure at all.
Weak: "The payment service calls the bank, then marks the order paid."
Strong: "If the bank call times out, we don't know if the charge went through. So every charge carries an idempotency key. On retry, the bank returns the original result instead of charging twice."
You don't need to cover every failure. Pick the two that would hurt users most and handle those well. That alone puts you ahead of most candidates.
5. Going deep on the wrong thing
Some candidates spend 20 minutes on database indexes for a URL shortener. Then they run out of time before they discuss the redirect path, which handles 99 percent of the traffic.
Depth is good. Depth in the wrong place is a time leak.
Weak: A long tour of B-tree internals while the core flow is still unfinished.
Strong: "The interesting part here is the read path, since reads outnumber writes 100 to 1. I'd like to go deep on caching for redirects. Does that sound right, or is there another area you'd prefer?"
Here is a time budget that works for most 45-minute rounds:
Finish a complete, simple design first. Then go deep. A finished simple design beats a half-finished clever one every time.
If you want structured practice with this flow, Grokking the System Design Interview works through full problems from requirements to deep dives.
6. Monologuing
Some candidates talk for 30 minutes straight. The interviewer tries to steer them twice. They don't notice.
A system design interview is a collaboration. The interviewer is often dropping hints about where they want you to go. If you're not listening, you miss them.
Weak: Twenty uninterrupted minutes, ending with "So, yeah, that's my design."
Strong: Short check-ins at natural breakpoints. "Here's the high-level flow. Before I go deeper, anything you'd like me to focus on?"
Treat it like pair programming, not a lecture.
7. One consistency model for everything
Candidates often pick "strong consistency" or "eventual consistency" for the whole system. Real systems mix both.
A like count can be a few seconds stale. Nobody cares. A bank balance can't be. A seat reservation can't be.
Weak: "We'll use eventual consistency because it scales better."
Strong: "Likes and view counts can be eventually consistent, so I'll batch them through a counter service. The order and payment records need strong consistency, so they go to a relational database with transactions."
Splitting your data by how much staleness it can tolerate is one of the clearest senior signals you can send.
Key Takeaways
- Ask scoping questions before drawing anything. Write the answers down.
- Every estimate should change a design decision, or it isn't worth computing.
- For every component, say why it's there and what it costs.
- Handle the two failures that hurt users most. Use idempotency for retries.
- Finish a simple end-to-end design before going deep. Choose depth where the load is.
- Check in with the interviewer at natural breakpoints.
- Match the consistency model to each type of data, not to the whole system.
FAQ
How many clarifying questions should I ask?
Usually four to six. Enough to pin down scale, core features, and the most important non-functional requirement. Don't turn it into a 15-minute interview of the interviewer.
Should I memorize designs for common questions?
Study them, but don't memorize final diagrams. Interviewers change one requirement and memorized answers fall apart. Learn why each design made its choices.
What if I don't know a technology the interviewer mentions?
Say so and reason from first principles. "I haven't used it, but if it's a log-based queue, I'd expect these properties..." Honest reasoning scores better than bluffing.
Is it bad to change my design mid-interview?
No. Spotting a flaw in your own design and fixing it is a strong signal. Say what you're changing and why.
How do I practice the communication part?
Do timed mock interviews out loud. If you can't find a partner, record yourself on a 45-minute timer and watch it back. You'll spot the monologues fast.
My interview is next week. Where do I start?
Review the core building blocks first, then do two or three timed mocks. The System Design Interview Crash Course is built for that kind of short runway.
Which of these mistakes have you seen, or made? Let me know in the comments.
Top comments (0)