System design interviews get a reputation for being unpredictable — the prompt varies, the interviewer's priorities vary, and there's no single correct answer to point at afterward. What's actually predictable is the process a strong candidate runs regardless of the specific prompt. Preparing for these interviews is less about memorizing architectures for common systems and more about internalizing a structure you can apply to a prompt you've never seen before.
Spend real time on requirements before designing anything
The most common mistake isn't a bad architecture — it's a good architecture for the wrong problem, produced by jumping to a design before the requirements are pinned down. Spend the first several minutes explicitly clarifying scope: what's the read and write volume, what's the acceptable latency, what's the consistency requirement, is this a system that needs to handle a specific hard case like a celebrity user with a hundred million followers, or is that out of scope for this conversation. An interviewer watching you ask sharp, specific clarifying questions is getting signal about how you'd behave on a real, ambiguous project — which is usually exactly what they're evaluating for, more than whether you land on their preferred final design.
Write the numbers down and use them. If you establish that the system needs to handle ten thousand writes per second, every subsequent design decision should be checked against that number, out loud, rather than existing as an unused fact you gathered at the start and never referred to again.
Build the design in layers, narrating trade-offs as you go
Start with a high-level design that would work for a much smaller version of the problem, then scale it up deliberately, explaining what breaks at each stage and why. This is more legible to an interviewer than starting with the fully scaled final architecture, because it demonstrates that you understand why each piece of complexity exists rather than reciting a pattern you've memorized. A candidate who can explain "a single database would work fine here up to roughly this scale, and here's specifically what breaks past that point" is showing more judgment than one who opens with a sharded, multi-region design for a system that doesn't need it yet.
Every non-trivial decision has a trade-off, and naming it out loud is worth more than the decision itself. "I'm choosing eventual consistency here because the write throughput requirement makes strong consistency expensive at this scale, and staleness for a few seconds is acceptable for this particular data" tells the interviewer you know there was a choice to make, which is frequently the actual thing being tested — not whether you picked the option they had in mind.
Manage the conversation, not just the whiteboard
A system design interview is a collaborative conversation, not a solo presentation, and treating it like the latter is a common way to run out of time on the wrong section. Check in periodically about whether to go deeper on a component or move on — "I could go deeper into how the cache invalidation works here, or move on to the notification service, which would you rather I focus on" — which does two things: it uses the interviewer's own priorities to guide your limited time toward what they actually want to evaluate, and it demonstrates a collaborative instinct that matters on real teams, where nobody designs a system in isolation without checking in.
Leave real time for the parts candidates tend to rush — failure modes, monitoring, and what happens when a component you designed goes down. These sections are often where the differentiation actually happens, precisely because most preparation time goes into the happy-path architecture and comparatively little goes into what happens when a piece of it fails.