A live system design interview is a synchronous, real-time conversation: the candidate designs a system out loud, on a call, while you watch and push back in the moment. That's the whole definition, but it's worth stating plainly because most of what goes wrong in these sessions comes from interviewers running a live interview like a take-home they happen to be watching. They hand over the prompt, go quiet, and grade the diagram at the end. That's not a live interview. That's a take-home with an audience, and it wastes the one thing the live format is actually good for.
This post is a run sheet, not a question bank. If you want a list of good system design prompts and what each one is built to test, we already covered that in system design interview questions worth asking. Here, the question you pick matters less than what you do in the 45 minutes after you ask it.
A take-home design doc is a good format for testing whether someone can produce a coherent, well-reasoned architecture on their own time, with no one watching. It's a fair test of the finished artifact.
It is a bad format for testing something else entirely: whether the candidate can think in front of you, take a constraint you just added, and change course without shutting down. That skill, reasoning live under a moving target, is what a live session exists to measure, and it disappears completely if you run the session as a monologue. If the whole 45 minutes is the candidate presenting a design they clearly rehearsed, with you nodding until the end, you've spent an hour to learn less than a take-home doc would have told you in ten minutes of reading.
So the first decision, before you pick a prompt, is whether you're actually going to use the live format for what it's for: interject, redirect, add a constraint mid-design, and watch what happens to the reasoning when the ground moves.
Most live system design slots run 45 to 60 minutes. Here's how we've seen that time hold up as an actual conversation instead of a lecture.
Tell the candidate explicitly how the session works before they start designing: "There's no single right answer, I'm going to interrupt with questions and new constraints as we go, and I'd rather you think out loud than get to a polished diagram." That one framing move removes most of the performance anxiety and gives you permission to interrupt later without it feeling like an ambush.
Give a deliberately underspecified prompt ("design a notification system") and say nothing else until they ask a clarifying question. If they start drawing boxes immediately, that's data: stop them gently and ask what scale and constraints they're assuming. A candidate who never asks what "notification system" needs to do is telling you something before the design has even started.
This is the core of the session and the part interviewers most often run passively. Let them lay out a first pass, then actively push:
The goal in this block is to never let more than three or four minutes pass without you saying something. Long silent stretches mean you've reverted to grading a monologue.
Pick the single riskiest part of what they've designed, the part where a wrong assumption would actually break something in production, and go deep on just that. If they proposed a queue for ordering guarantees, ask what happens on a duplicate delivery. If they proposed eventual consistency for a counter, ask what the product owner sees when two counts disagree on screen at the same time. You're not trying to catch them out; you're finding out whether the confidence in minutes 10 to 30 was backed by something.
Ask what they'd do differently with another hour, and what they're least confident about in what they just designed. Candidates who can name their own design's weak point unprompted are showing you the exact judgment the whole interview was built to surface. This is also the fastest way to get the session's most useful sentence: their own next question.
The mechanics above only work if the way you interrupt doesn't read as a gotcha. The difference is small but it's everything: a colleague pushes back because they're actually trying to build the thing with you ("wait, what happens if that call times out?"), while a proctor interrupts to test whether you'll trip ("aha, but what about failures?"). Say it like you'd say it in a real design review, in the same tone you'd use with someone already on your team, and most candidates relax into it instead of freezing.
The other common failure is the opposite one: interviewers who are so worried about seeming adversarial that they never push at all, and the session drifts into forty-five minutes of the candidate talking uninterrupted. If you notice you haven't spoken in five minutes, that's the signal to jump in, not evidence that things are going well.
Three tools show up in live system design interviews, and they trade off differently:
None of these is universally right. A whiteboard is enough for an architecture-level conversation where building anything would take days regardless of who's doing it. Reach for a live environment specifically for the piece of the design that carries real risk, the part where you actually want to know if the candidate believes their own answer enough to build it that way.
Being candid about the format's limits matters as much as selling its strengths. A live session is a bad fit when the value you're actually trying to assess is sustained, unobserved work: whether someone can sit with an ambiguous problem for two hours, iterate on their own, and produce a coherent artifact without a partner in the room prompting them. That's exactly what a take-home design doc is for, and no amount of clever interjecting recreates it live. We wrote a separate guide on making that format worth a candidate's Saturday in take-home challenges: how to make them worth a Saturday.
Live is also the wrong call when your team hasn't agreed on what a strong answer looks like before the candidate walks in. Two interviewers running the same "steer and stress-test" loop with different personal bars will produce two different verdicts on the same candidate, and the live format's flexibility makes that drift worse, not better, because no two sessions ask exactly the same follow-ups. A shared scorecard, like the one in the practical interview scorecard, is what keeps "I pushed on the failure case and they held up" comparable across a panel instead of becoming one interviewer's gut feeling.
Candidates walk into most system design interviews having read the same handful of primers everyone reads, including the widely used system-design-primer on GitHub, and they arrive with a script: cache it, shard it, queue it. That script survives a passive interview intact, because nothing in a passive interview asks the candidate to leave it. It does not survive minutes 10 to 40 above, because a constraint you just invented and a service that just broke are not in the script.
The sessions we've seen land best are the ones where the interviewer treats the 45 minutes as a working conversation about a real problem, not a presentation to be graded afterward, and where the riskiest part of the design gets built, even briefly, instead of only described.
Write down, before the call, the two or three constraints you plan to add and the one failure mode you're going to push on. Say the framing out loud in the first five minutes. And if there's a piece of the design where a wrong assumption would actually break something, consider handing the candidate a live environment for just that piece instead of leaving it as a diagram.
What would change about your last live system design interview if you'd spoken up every four minutes instead of waiting for the diagram to finish?
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Most backend engineers can write SQL and far fewer can work out why a query got slow last Tuesday. Here is how to interview for that, on a real database with real data volume, and what separates the three levels of answer.
When the candidate pairs with an AI instead of with you, the assessment moves from writing code to judging it. Here is what to watch, how to design a task the model cannot finish alone, and what a strong session actually looks like.
Read more
Hiring managers are now expected to judge how well candidates work with AI, mostly without having done it themselves on real work. Here is the minimum literacy you need to run that round honestly, and the four questions that expose whether you have it.
Read more
