Preparing for system design interviews.

What interviews actually test

Not whether you can draw a load balancer. Whether you can justify a choice, name what it costs, and change your mind when given new constraints. Candidates who have memorised diagrams fall over on the first follow-up because a memorised diagram carries no reasoning, and the follow-ups are the interview.

Reference designs with the arguments

There are 24 worked architectures covering the systems that come up most, and each one carries three to five design decisions written out with what they cost: why counter ranges beat hashing for a URL shortener, why fan-out on write breaks for high-follower accounts, why payment systems need idempotency keys. Reading the argument is the part that transfers; the boxes are not.

Practise redrawing quickly

Being able to produce the shape fast, and restructure it when a constraint changes, is a real skill and it improves with repetition. Because layout is computed, adding a cache or splitting a service costs one edit rather than a rearrangement, so a practice session covers more ground.

Be honest about the room

Most interviews happen on the interviewer's whiteboard tool, so this is preparation rather than something you will use during the interview. Anyone suggesting otherwise is selling you something.

A practice session

Related

• Onboarding Engineers to a Codebase
  The first week is spent building a mental model that somebody already has. A diagram transfers it in an afternoon.
• Documenting Legacy Code
  Including the newest kind of legacy code: what a coding agent wrote for you over several sessions that nobody has looked at as a whole.
• Architecture Review
  Most of the effort in an architecture review goes into producing the diagrams, and most of those diagrams describe the system as remembered rather than as built.
• Technical Design Documents
  The diagram in a design doc usually gets drawn last, badly, because everyone is tired of the document by then.