What is a system design interview?
A system design interview asks you to architect something — a URL shortener, a news feed, a rate limiter — out loud, on a whiteboard. There is no single right answer; the interviewer is watching how you think, clarify, and reason about trade-offs under ambiguity.
Why it matters
For mid and senior backend roles, system design is often the deciding round. Strong coders fail it by jumping to a solution without scoping the problem. A clear, structured approach signals the judgment teams hire for. It is a learnable format, and practice pays off directly.
What to learn
- A repeatable structure: requirements, scale, API, data, design, bottlenecks
- Clarifying functional and non-functional requirements first
- Estimating scale with back-of-the-envelope math
- Sketching the API and data model before the boxes
- Identifying bottlenecks and addressing them with known tools
- Discussing trade-offs out loud
- Driving the conversation without rambling
Common pitfall
Jumping straight to drawing boxes and databases before clarifying what is being built and at what scale. The interviewer wants to see you scope the problem — ask about users, traffic, and constraints — first. Diving into a solution for a problem you have not defined is the most common way strong engineers fail this round.
Resources
Primary (free):
- System Design Primer · docs
- ByteByteGo — System design 101 · docs
- Google SRE — The book · docs
Practice
Pick a classic prompt — design a URL shortener — and work through it on paper using a fixed structure: clarify requirements, estimate scale, define the API and data model, sketch the design, then name the bottleneck and a fix. Time yourself to 40 minutes. Done when you followed the structure without skipping to the solution.
Outcomes
- Drive a design interview with a repeatable structure.
- Clarify requirements and scale before designing.
- Estimate capacity with back-of-the-envelope math.
- Discuss trade-offs and bottlenecks out loud.