Six System Design Interview Mistakes—and the Drill for Each

Knowledge gaps and performance gaps need different repairs.

A candidate may know databases, queues, and caching yet still produce a weak round. The failure may be sequencing, vague language, missed constraints, or an inability to recover after a challenge.

After a mock, record the first observable moment the answer lost coherence. Repair that behavior directly. Rewatching another full architecture walkthrough is rarely the narrowest intervention.

Premature architecture: drawing before the contract is clear.

The candidate hears a familiar product name and immediately draws clients, services, a cache, and a database. The diagram may look plausible while solving a different problem from the one the interviewer intended.

Repair drill: take five prompts and forbid yourself from drawing. Produce only users, core flows, exclusions, and ranked non-functional requirements. Stop when you can state the product contract in three sentences.

Estimate theater: doing arithmetic that changes nothing.

Long calculations consume time but do not demonstrate judgment unless they affect a boundary, data model, throughput strategy, or reliability decision.

Repair drill: for each estimate, finish the sentence: therefore I will. If the design is identical at one-tenth or ten times the result, mark that estimate as optional.

Component cataloging: naming tools without assigning responsibility.

Saying queue, cache, NoSQL, and CDN is not a design. Each box needs an owned decision: what data or work crosses it, why the boundary exists, and what happens when it fails.

The same rule applies to protocols. REST, GraphQL, gRPC, server-sent events, and WebSockets are not interchangeable sophistication badges. Repair drill: point at every box and boundary in a completed diagram and answer what enters, what leaves, which interaction pattern is required, and what promise it protects. Remove anything whose job you cannot state.

Tradeoff fog: using “it depends” without naming what it depends on.

Nuance is valuable, but vague conditional language hides the decision. Strong answers name the controlling constraint, choose an option for the stated scenario, and acknowledge the cost.

Repair drill: use a three-part sentence—Because this workload values X over Y, I choose A; the cost is B. Practice it for storage, consistency, caching, partitioning, and synchronous versus asynchronous work.

Reliability as an appendix instead of a property of the path.

Adding replicas and retries at the end does not explain how the system behaves under partial failure. Retries can amplify load; replicas can lag; queues can redeliver.

Repair drill: replay the critical path with one dependency slow, one message duplicated, and one worker crashing after a side effect. State detection, containment, and recovery for each case.

Invisible reasoning: silently thinking, then announcing a choice.

The interviewer cannot score reasoning they never hear. At the opposite extreme, narrating every thought produces noise. The goal is to expose decision points, not stream consciousness.

Repair drill: before each material choice, state constraint, options, choice, and cost in under thirty seconds. Record yourself and remove setup that does not change the decision.

Use an evidence log, not a single score.

For each checkpoint—scope, scale, interfaces, architecture, tradeoffs, reliability, communication—capture one timestamped example of strong or weak behavior. Then choose one repair drill for the next session.

A total score can show direction over time, but it cannot tell you what to practice tomorrow. Evidence can.

• Observed behavior: what the candidate said or did
• Consequence: what became unclear, incorrect, or slow
• Repair: one bounded drill
• Retest: the prompt that will reveal whether behavior changed