The system-design interview format

Load balancers, caching, database sharding, CAP theorem trade-offs — those concepts live in this app's System Design domain, and this lesson assumes you already have that grounding. What trips people up in the actual interview usually isn't a knowledge gap; it's the unfamiliar shape of the conversation itself: an open-ended prompt, a whiteboard, a ticking clock, and an interviewer who's deliberately vague at first.

"Design a URL shortener" or "design Twitter" is not a complete spec — it's an invitation to demonstrate that you know which questions to ask before designing anything. Jumping straight to a solution for an unscoped problem is one of the most common ways this round goes wrong, because the interviewer has no way to see the requirements-gathering instinct that day-to-day system design actually depends on.

Spend the first several minutes narrowing the problem out loud:

A rough estimate of requests per second, storage growth per year, or read:write ratio doesn't need to be precise — it needs to exist, and it needs to visibly inform decisions later ("at this write volume, a single relational database should be fine without sharding yet — I'd revisit that assumption if we were two orders of magnitude higher"). Skipping this step is what leads to over-engineering a solution that a much simpler design would have handled fine at the actual scale requested.

Draw the major components and how data flows between them before diving into any one part in detail. A good system-design candidate treats the interviewer's questions as steering input, not as gotchas — if they ask "what happens if this service goes down," that's a direct signal about which part of the design they want examined next, not an attempt to catch a mistake.

"I'd use a NoSQL store here" is a weaker answer than "I'd lean toward a NoSQL store here because we don't need strong relational joins across this data and we're optimizing for write throughput at this scale — the trade-off is losing easy ad-hoc querying, which I'd accept given the requirements we scoped." The second version demonstrates the actual reasoning skill the round exists to test; the first just states a conclusion the interviewer has to take on faith.

A 45-minute round spent entirely on requirements gathering never reaches a design at all; one that jumps straight to deep implementation details never demonstrates breadth. A rough allocation — a few minutes scoping, a few on estimation, the bulk of the time on the high-level design and whatever area the interviewer steers into — keeps the conversation from stalling in any one phase. It's reasonable to say out loud, "I want to make sure we get to the data model — should I move on from this part?"