Things to Avoid During System Design Interview

Things to Avoid During a System Design Interview

A system design interview is not a knowledge quiz — it is a simulation of how you behave as a senior engineer under ambiguity. The interviewer already assumes you know what a load balancer is. What they cannot tell from your resume is: do you clarify before you build? Do you make decisions for reasons, or by reflex? Can you defend a choice and then abandon it when the numbers change? This lesson exists because most candidates lose the offer not by lacking knowledge, but by displaying the wrong instincts — the same anti-patterns that make a real engineer expensive to work with. Learning what to avoid is faster than learning every technology, because there are only a handful of fatal habits and they repeat in every debrief.

How the evaluation actually works

Interviewers score against a rubric, usually four axes: requirements & scoping, high-level design, deep dives & trade-offs, and communication. Each anti-pattern maps to a zero on one of these axes. The mechanism is signal-based: the interviewer is collecting evidence for a hire/no-hire writeup they must justify to a committee. A single strong negative signal ("jumped to a solution before understanding the problem") can outweigh several positives, because it predicts on-the-job behavior. So the goal is not to be flawless — it is to avoid emitting a disqualifying signal. Below are the ones that reliably do.

1. Jumping straight to the solution

The single most common failure: hearing "design Twitter" and immediately drawing Kafka, Redis, and Cassandra boxes. This signals you optimize before you understand — the exact behavior that produces over-engineered, unmaintainable systems in production. Spend the first 5–10 minutes (of a 45-minute interview) on requirements. Separate functional requirements (post a tweet, view a timeline) from non-functional ones (availability, latency, consistency), and explicitly scope out what you will not build.

2. Skipping back-of-the-envelope estimation

Numbers drive design. If you never compute load, every component choice is arbitrary and you cannot defend it. Do the math out loud before choosing storage or caching.

3. Not driving the conversation

Silence, or waiting to be asked the next question, reads as junior. A senior candidate owns the whiteboard: states assumptions, proposes a path, and narrates trade-offs continuously. Equally bad is the opposite — steamrolling the interviewer, ignoring their hints. Those hints are gifts; when they say "what happens if that node dies?", they are steering you toward the deep-dive they want to score. Treat every prompt as a redirect toward points.

4. Buzzword-driven design (resume-driven architecture)

Saying "we'll use Kafka, Kubernetes, and a service mesh" without justifying why invites exactly the follow-up that exposes you: "Why Kafka over a simpler queue like SQS or RabbitMQ?" If you can't answer, the buzzword becomes a liability. Introduce a technology only after the requirement that demands it. Name the problem, then the tool — never the reverse.

5. Ignoring bottlenecks, failure, and the data model

Green-path designs where nothing ever fails are a red flag. Real systems degrade: nodes die, networks partition, caches go cold, hot keys form. Not discussing the database schema, access patterns, and single points of failure leaves the biggest scoring section (deep dives) empty.

A worked scenario: the estimation that anchors everything

Suppose you're asked to design a URL shortener. Instead of drawing boxes, do the numbers: assume 100M new URLs/day. That's roughly 100M / 86,400s ≈ 1,160 writes/sec. Reads dominate shorteners at maybe 100:1, so ~116,000 reads/sec. Storage: at ~500 bytes/record and 100M/day, that's 50 GB/day, or ~18 TB over a year — comfortably fits on a few nodes, so you do not need exotic sharding on day one. The short-code space: base62 with 7 characters gives 62^7 ≈ 3.5 trillion URLs — decades of runway.

Now the design writes itself from the numbers: 116K reads/sec means a read-through cache (Redis) is mandatory and the DB can be read-replicated; 1,160 writes/sec is trivial for a single primary, so you don't need write-sharding yet. Every box on your diagram is now justified by a figure, and when the interviewer pushes ("what if it's 10x?"), you scale the same numbers instead of panicking. This is the exact opposite of the buzzword approach — the same 3 minutes of arithmetic turns arbitrary choices into defensible ones.

Trade-offs: when these "rules" bend

The advice above is default behavior, not dogma. Knowing when to break it is the senior signal.

• Time spent scoping vs. building. The rule is ~7 minutes on requirements. But if the interviewer says "assume the requirements, just design it," respect that — over-clarifying then becomes stalling. Read the room; scoping is a means to a defensible design, not a ritual.
• Simple vs. sophisticated. Prefer the simplest thing that meets the stated load (single DB + cache beats a sharded multi-region cluster for 1,160 writes/sec). But if the prompt explicitly says "global, 500M DAU," reaching for boring simplicity now under-shoots and reads as not knowing the advanced tools. Match sophistication to the stated scale — both under- and over-engineering are failures.
• Breadth vs. depth. Covering ten components shallowly loses to covering the two hardest deeply. But go too deep on one niche (e.g., the exact Raft log-compaction algorithm) and you'll run out of clock before showing an end-to-end system. Cover the whole flow once, then deep-dive where the interviewer points.
• Driving vs. listening. Own the direction, but a hint is a course-correction with points attached — always take it over your own plan.

Pitfalls an interviewer specifically probes

These are the scripted follow-ups used to separate levels. Rehearse them.

• "Why this database?" — Answering "because it scales" fails. They want the CAP trade-off in your context: SQL for transactional integrity and joins, NoSQL (wide-column/KV) for high write throughput and denormalized access. Tie it to your access patterns.
• "What's your single point of failure?" — If you can't name one, you haven't thought about failure. Every design has them; show you can identify and mitigate (replication, failover, multi-AZ).
• "What breaks at 10x load?" — Probes whether your numbers were real. Point to the component that saturates first (usually the DB primary or a hot cache key) and how you'd shard or partition it.
• "How do you keep the cache and DB consistent?" — Naming a strategy (write-through, write-back, cache-aside with TTL) and its staleness trade-off signals depth; hand-waving "we cache it" signals you've never operated one.
• Consistency vs. availability under partition — If you claim "strongly consistent AND highly available," they will invoke a network partition and watch you contradict yourself. Know which one you're sacrificing and why.

Key takeaways

• Understand before you build. The fatal signal is jumping to a solution; spend the first ~10 minutes on requirements + back-of-envelope numbers, and let those numbers generate every component choice.
• Justify, don't name-drop. Introduce each technology only after the requirement that demands it; be ready to defend it against a simpler named alternative, and to abandon it when the load figures change.
• Spend your clock where the points are. Cover the whole flow once, then invest the largest slice in deep dives — failure modes, data model, bottlenecks, and consistency — because that is the highest-weighted rubric axis.
• Communication is scored. Drive the conversation, state assumptions aloud, and treat every interviewer hint as a redirect toward points rather than an interruption.