System Design Interview: Narrate Before You Draw
Most system design freezes happen in the first three minutes. People draw random boxes because silence feels worse. Random boxes are worse than silence with a plan.
Minute 0–2 — Product clarity
Ask:
- Who is the user?
- Core actions (read/write ratio)
- Critical success metric (latency, freshness, cost)
- What is explicitly out of scope
Write non-goals. Interviewers love non-goals.
Minute 2–4 — Constraints and scale
Rough numbers: DAU, QPS, payload size, retention. Back-of-envelope is expected. Wrong by 10× is fine if the method is clear. Wrong by silence is not.
Minute 4–5 — Sixty-second story
Before drawing: “Clients hit an API gateway; writes go to X; reads are served from Y; async path for Z.” One story. Then draw that story.
Drawing rules
- Name every box with a responsibility
- Show the request path for the core use case first
- Add complexity only when a requirement forces it
Deepening without drowning
Pick one axis to go deep: data model, consistency, failure modes, or scaling bottleneck. Signal the choice: “I’ll go deep on consistency for the feed fan-out.”
Common failure modes
- Jumping to Kafka because it is fashionable
- No estimate of storage or QPS
- Ignoring failure (what if the cache dies?)
- Designing five products in forty-five minutes
Practice
Explain a known system (URL shortener, news feed, chat) with a timer: two minutes talk-only, then draw. Record the talk. If you cannot tell the story without the board, you are drawing to think—and interviewers can tell.
Side-panel rehearsal tools for live rounds (Luna Interview) can help you keep prompts and notes visible while you practice the spoken story. The skill is still narration.
Closing
Boxes are cheap. A coherent story is the product. Narrate first.
Rehearse with an AI interview copilot, then browse commonly reported interview questions.