How a system design interview works

For this lesson, we'll look at the round from the interviewer's side of the table: how the hour is usually split, what actually goes on the scorecard, and how the bar moves between mid-level, senior and staff. Interviewers lean on this round because it's the closest thing to watching you work on a real design review, and it's very hard to fake with memorised answers.

01Picture it first: a design review with a stranger

Think of the round as a design review at a new job, where a senior colleague asks you to sketch a system you've never built together. They know where the hard parts are. You don't know them yet, and you have an hour. They're not checking whether your drawing matches some answer key. They want to know: if this person joined my team, would their design reviews be worth attending?

That framing explains almost everything about the format. The prompt is vague because real projects start vague. The interviewer interrupts because real colleagues push back. And the clock matters because a design review that never reaches the hard part is a wasted meeting.

02How the hour is usually split

Most companies run a 45 or 60 minute slot. A 60 minute slot often loses 5 minutes to introductions at the start and 5 to 10 minutes to your questions at the end, so you really have about 45 minutes of design time. Plan for that, not for 60.

These numbers are a guide, not a law. Some interviewers skip the API and want to get straight to boxes. Others will stop you at minute 12 and say "assume it needs to handle a billion users, go". Steering is information.

03What the interviewer actually scores

Every company words its rubric differently, but in my experience they boil down to the same four signals.

Problem navigation

Can you take a vague prompt and turn it into a problem worth solving? This shows up as the questions you ask early ("Do users need to edit a short link after creating it?"), the scope you state out loud, and later, the parts you choose to go deep on. A strong candidate spends their time where the risk is. A weak one spends 10 minutes on the login page of a video streaming system.

Solution design

Does the design actually work? I should be able to pick any functional requirement and trace a request through your boxes from client to storage and back. Strong designs are often boringly simple at first. Weak ones have impressive components that nothing connects to, or a database that's never written to.

Technical depth

When we go deep, do you know how the pieces behave? This is where you choose between options, say what each costs, and back the choice with a number: "A single Redis node handles our read load comfortably, but the dataset doesn't fit in one node's memory, so we shard by key." Naming Kafka isn't depth. Explaining why a partitioned log fits this workload, and what happens when a consumer falls behind, is.

Communication

Can I follow your thinking, and can we work together? Strong candidates think out loud, check in at the end of each phase, and take a hint as a gift instead of a threat. Weak ones go silent for two minutes, or talk for ten without looking up. Communication is the only signal that's scored in every minute of the round.

04How the bar moves with level

The prompt is often identical across levels. What changes is how much of the work you're expected to do without help, and how far past the basic design you get.

A useful way to remember it: mid-level candidates solve the problem they're given, seniors find the hard problems inside it, and staff candidates question whether it's the right problem. A mid-level candidate who gets through a clean design and one good deep dive has usually done well. A senior candidate with the same performance often hasn't, because nobody saw them lead.

Here's how I'd open, and why each sentence is there:

1. "Before I draw anything, I'd like to spend a few minutes on requirements so we design the right thing." (You're signalling that you'll drive, and that there's a plan.)
2. "My guess is the core features are creating a short link and redirecting from it, and that custom aliases and analytics might be stretch goals. Does that match what you had in mind?" (You propose instead of interrogating. That's problem navigation.)
3. "And roughly what scale should I design for: how many new links a day, and how many redirects?" (You ask the question whose answer will change the design.)

Notice what's missing: no technology names, no diagrams, no estimates yet. Those come once you know what you're building. The delivery framework walks through the whole URL shortener with this structure, step by step.

05What happens behind the curtain

It helps to know how the round looks from the other chair. Most interviewers have a short list of probes they plan to use for a given prompt: "What happens when this shard gets hot?", "How does a user see their own write?", "What if this service goes down?". If you raise a probe yourself before they get to it, that's a strong signal, because it shows you'd catch the problem in a real review.

Hints are also part of the format. If an interviewer says "What if traffic is 100 times higher during a live event?", they're not trying to trick you. They're handing you the deep dive they want to see. Candidates who pick up hints quickly usually score better than candidates who needed no hints but steered the round somewhere dull.

Finally, the write-up. After the round, the interviewer turns their notes into evidence for each signal, with quotes and moments: "Identified the hot-key problem unprompted", "Needed two hints to consider caching". That's why thinking out loud matters so much. A good idea you only had in your head can't go into the write-up.

06How to say it in the interview

When I run this round, I'm listening for a candidate who takes charge of the hour without ignoring me. You show it through the order you work in and how you check in.