Driving the Interview

Start here: the interview scores two things, not one#

When you sit down for a system design interview, it feels like there's one job: produce a good design. There are really two. The first is the design — the components, the data model, the tradeoffs. The second is everything the interviewer learns about how you work while you build it. Can you take a vague prompt and turn it into a plan? Do you say what you're thinking, or only what you've concluded? When the ground shifts, do you adapt or freeze? That second job is scored on almost every rubric, and it's the one candidates forget exists.

Here's the uncomfortable part. The interviewer can't read your mind. They can only grade what you say and do out loud. If you work out a brilliant tradeoff silently in your head and then state the conclusion, they didn't see the reasoning — so on the rubric, the reasoning didn't happen. Two candidates with identical knowledge diverge here. The one who narrates their thinking gets credit for it. The one who keeps it internal gets credit only for the final answer, and looks less thoughtful than they actually are.

The behavior that ties all of this together has a name: driving. Driving means you own the direction of the conversation. You decide what to tackle first, you propose the next step, you set the pace. The opposite is waiting to be led — sitting back until the interviewer asks 'okay, what about the database?' and answering only that. A candidate who waits to be led forces the interviewer to do the work of running the interview, and that reads as a lack of seniority. The message it sends is: this person needs a manager to make progress.

The behaviors, one at a time#

Driving isn't a personality trait you either have or don't. It's a set of concrete behaviors you can practice. Here are the eight that do the most work, each one something you can actually say or do in the room.

1. Clarify first, but don't interrogate. Before you design anything, ask two or three sharp questions to pin down the scope. Not twenty — two or three that actually change the design. Good ones: how many users, is it read-heavy or write-heavy, do we need the data instantly or is a short delay fine. Each answer should rule something out or point you somewhere. The goal is a scoped problem, not an exhaustive requirements document. Fire off fifteen questions and you look like you're stalling; ask the three that matter and you look like someone who's built real systems.

2. State your assumptions out loud, then move. You will never get every detail nailed down, and you shouldn't try. When something is unspecified, say what you're going to assume and keep going: 'I'll assume we need to support around ten million daily users and that a few seconds of delay on the feed is acceptable — tell me if that's off.' Now you're moving, and you've handed the interviewer a cheap chance to correct you. This is far stronger than freezing until you have permission for every choice. Waiting for permission on each detail is slow, and it puts the burden of driving back on them.

3. Think aloud. This is the single highest-value habit. Narrate the tradeoff, not just the verdict. Instead of 'I'll use a message queue,' say 'The producer is way faster than the consumer here, so if I call the consumer directly, a spike will overwhelm it. A queue lets me absorb the burst and process at a steady rate — that's why I'll put one here.' Same decision, but now the interviewer saw the reasoning. They're grading your judgment, and judgment is only visible when you speak it. A conclusion with no reasoning attached is worth a fraction of the same conclusion with the 'why' out loud.

4. Time-box yourself. You have roughly 45 minutes and a lot of ground to cover. Do not sink fifteen of them into one corner. If you catch yourself deep in the weeds on, say, the exact eviction policy of a cache, name it and pull up: 'I could go deeper on eviction, but I want to make sure we cover the overall data flow — I'll come back to this if we have time.' Deciding what deserves your minutes is itself a judgment the interviewer is grading. Spending your whole budget perfecting one component while the rest of the design stays blank is a classic way to run out of time with an incomplete answer.

5. Drive the structure. At each transition, propose the next step instead of waiting for it. 'I've got the high-level components. I'll move to the data model now, unless you'd like to go deeper on any of these first.' You're steering, and you're checking in — both at once. A useful default arc to drive through: clarify the requirements, sketch the high-level design, go deep on one or two core components, then talk about how it scales and where it breaks. You don't have to follow it rigidly, but having a spine means you're never standing at the whiteboard wondering what to do next.

6. When they say 'now scale it 10x,' name what breaks first. This is a favorite move, and there's a right order to answer it. Don't jump straight to a fix. First identify the bottleneck — the part that falls over first under the new load. 'At 10x traffic, the single database is the first thing to break: the write volume will exceed what one node can handle.' Then fix that specific thing: 'So I'd shard the database by user ID to spread the writes.' Naming the bottleneck before the fix shows you reason from the constraint, not from a memorized list of scaling tricks. It's the difference between diagnosing and pattern-matching.

7. Treat the interviewer's questions and hints as signals. When an interviewer asks about a specific part or drops a hint, that's not idle curiosity. It almost always means 'go here.' If they ask 'how does the cache stay consistent with the database?', they're telling you consistency is where the points are. Take the nudge and go there. Candidates who plow past a hint to stick with their own plan look like they can't take direction — and they miss the exact area the interviewer wanted to see. So when you get a hint, follow it.

8. Manage silence and recover from being stuck. You will get stuck; everyone does. The trick is to not go silent while it happens. Narrate the pause: 'Let me think about the tradeoff here for a second.' That one sentence turns dead air into visible, deliberate thinking. If you're genuinely blanking, reason out loud from what you know: 'I'm weighing two options here — let me talk through both.' Thinking out loud through a hard spot is a strength signal. Freezing silently is the thing that reads as panic.

Reading the interviewer and pacing the clock#

The behaviors above are the raw moves. The harder skill is knowing when to use each one, and that comes down to reading the interviewer and watching the clock. This is the part that separates someone who's memorized 'the steps' from someone who can actually run a live conversation.

Read the interruptions. When an interviewer cuts in while you're talking, they're almost always steering you. If they interrupt to ask a pointed question about one component, they usually want more depth there — so go deeper, don't wave it off and return to your script. If they interrupt to say 'okay, let's assume that part works, what about X,' they're telling you you've spent enough time here and X is where the remaining points live. Either way, the interruption is information. The candidate who treats every interruption as a detour to survive misses that it's a map.

Pace across the whole 45 minutes. A rough budget: about five minutes clarifying and scoping, ten sketching the high-level design, fifteen to twenty going deep on the core pieces, and the last ten on scaling and failure modes. You don't need a stopwatch, but you do need a rough sense of where you are. If you're twenty-five minutes in and still drawing boxes for the basic flow, you're behind, and you should deliberately speed up and move to depth. Running out of time with the interesting parts untouched is one of the most common ways a strong candidate underperforms.

Recognize a rabbit hole and climb out. The dangerous rabbit holes are the ones that feel productive — you're talking fluently, you know this corner well, so you keep going. Meanwhile the clock is burning and the design is lopsided. The tell is when you've been on one sub-problem for several minutes and it isn't one of the core pieces. The move is to name it and pull up: 'This is a detail I'm happy to go deeper on later, but let me zoom back out to the main flow.' That sentence proves you can tell the important from the merely interesting — which is exactly the judgment being scored.

The tensions you have to balance#

Every one of these behaviors can be overdone. Driving well is about holding a few tensions in balance, not maxing out a single dial. Here are the three that matter most.

Driving versus steamrolling. Yes, you own the direction — but the interviewer is a participant, not an audience. If you talk for ten minutes straight without pausing, ignore their questions, and bulldoze through their hints, you've stopped driving and started steamrolling. It reads as someone who doesn't collaborate. The fix is built into the behaviors already: propose the next step, then check in ('unless you'd like to go deeper here'). Leave room. Watch for them wanting to speak. Driving is leading a conversation, and a conversation has two people in it.

Depth versus breadth. You can't go deep on everything in 45 minutes, and you can't stay shallow on everything either. The balance is to cover the whole system at a high level so nothing important is missing, then go deep on the one or two components that carry the real complexity. A design that's uniformly shallow looks like you don't know how anything actually works. A design that's deep on one corner and blank everywhere else looks like you lost the plot. Aim for a complete skeleton with muscle on the parts that matter.

Confidence versus humility. You want to sound like you can make decisions, but not like you're bluffing. The trap is pretending to know something you don't. Interviewers are very good at spotting a confident guess, and getting caught bluffing costs you their trust for the rest of the interview. The strong move when you hit the edge of your knowledge is to be honest and stay useful: 'I'm not certain of the exact answer here, but here's how I'd reason about it,' and then reason. That shows confidence in your thinking without faking facts. Honesty about a gap, paired with a method for closing it, beats a confident wrong answer every time.

Two candidates, same knowledge, different score#

The clearest way to see why this matters is to put a driven candidate next to a passive one who knows exactly the same material. The knowledge is identical. Only the behavior differs — and the scores don't.

Notice that in every row, the two candidates could reach the same final design. The difference is that the interviewer got to watch the driven candidate think, adapt, and lead — and got almost none of that from the passive one. The rubric rewards what it can see. The driven candidate simply made more of their competence visible.

This is also the main axis on which interviewers read seniority. A junior signal is treating ambiguity as a problem to be solved by asking the interviewer to remove it — 'what should I assume for the scale?' A senior signal is treating ambiguity as normal and handling it yourself — 'I'll assume this scale and design for it; here's how the design would change if it's actually much larger.' Same ambiguity, opposite posture. One asks to be rescued from the unknown; the other navigates it and narrates the navigation. Interviewers are explicitly listening for which one you are, because it predicts how you'll behave on a real underspecified project.