Skip to content
System design course
Ch.1 · Cracking the system design interview·concept ·7 min read

What a system design interview actually tests

It's not about the "right" diagram — it's about how you reason through an open-ended, ambiguous problem under constraints.

The thing being measured

A coding interview has a hidden answer key: the tests pass or they don’t. A system design interview has none. You’re handed something deliberately vague — “design Twitter” — and the interviewer watches how you think, not whether you land on one blessed architecture.

Concretely, a strong candidate shows four things:

  • Structured thinking — you turn a fuzzy prompt into scoped requirements, rough numbers, and a plan, instead of free-associating about technologies.
  • Breadth — you know the standard building blocks (load balancers, caches, queues, replicated stores) well enough to reach for the right one.
  • Depth on demand — when the interviewer points at one box, you can go three levels deeper into it without hand-waving.
  • Trade-off judgement — you can say “I’d pick X over Y here because we’re read-heavy and can tolerate stale data,” and mean it.

What it is not

  • Not trivia. Naming a database is worthless if you can’t say why it fits.
  • Not a memory test. Reciting a blog post’s architecture for “design YouTube” fails the moment the interviewer changes one requirement.
  • Not about finishing. Nobody designs all of Uber in 45 minutes. You’re expected to scope hard and go deep on a slice.

The shape of a good session

Think of it as a guided conversation you drive:

  1. Clarify the problem — turn the one-liner into concrete requirements.
  2. Estimate scale — a few back-of-the-envelope numbers that justify later decisions (sharding, caching, replication).
  3. Sketch a high-level design — the boxes and arrows for the happy path.
  4. Drill down — pick the interesting components and design them properly.
  5. Stress it — talk bottlenecks, failure modes, and trade-offs.

The rest of this chapter is each of those steps. The mental model to carry through: every decision should trace back to a requirement or a number. If you can’t say why, you’re guessing, and the interviewer can tell.

Junior vs senior signal

The same prompt is graded differently by level. Juniors get credit for a sane, working high-level design. Senior and staff candidates are expected to lead the conversation, surface trade-offs unprompted, reason about scale and failure, and know when not to add complexity. Match your depth to the role, but the framework is identical.