A live coding interview is the one stage in a technical screen that a candidate can't fake by copying a polished GitHub repo or asking a friend to review their code overnight. You watch someone think in real time: how they read a problem, what they ask before they start typing, what they do when their first approach doesn't work. That's also why it's the stage most hiring teams run badly. Get the problem, the timing, or the scoring wrong and you either scare off a strong engineer who freezes under a stranger's gaze, or wave through someone whose code came from an AI assistant they can't actually explain.
What is a live coding interview?
A live coding interview puts a candidate and an interviewer on the same call, working through a problem out loud, typically for 45 minutes to an hour. It sits between two stages people often confuse it with. A take-home is unsupervised and untimed: the candidate submits a finished artifact days later, and you never see the reasoning behind it. Jason Swett, who runs these sessions from the interviewer's side, makes the case for live over take-home on exactly that gap: a take-home only shows the end product, not how the candidate arrived at it. The full technical screening process is the broader filter a live session sits inside, usually as the closing stage after a background check, a communication conversation, and a take-home project.
None of this replaces a coding assessment platform for high-volume screening earlier in your funnel. If you're filtering hundreds of applicants before any of this starts, an automated tool still earns its subscription; five of the major ones compared side by side do that job well. The live session is a later, more expensive stage, reserved for candidates who already cleared that first filter, and it tests something a test-case score can't: whether the person understands the code in front of them.
How to run a live coding interview
1. Choose a problem that mirrors real work
Pick a problem close to something the person would actually do in the role: debug a function with a subtle off-by-one error, extend a small existing codebase, or clean up working but ugly logic. Skip inverted-binary-tree puzzles and other algorithm-trivia questions that reward memorized patterns over judgment. A senior candidate who's forgotten a textbook algorithm they'll never hit in production isn't a worse hire than one who crammed it last week. Hire developers by tech stack: rates, vetting and interview guides breaks down what a role-specific problem should test for React, Python, Go, and the other stacks HighCircl covers. Start there instead of a generic question bank.
2. Time-box the session and share the format in advance
Tell candidates the format before the call: how long it runs, what tools they'll have, and roughly what kind of problem to expect, whether that's debugging, a feature extension, or a code review. Marcus Rådell's advice on running these sessions is blunt: make the candidate comfortable, or don't do it. Surprise format changes and unclear time limits mostly measure how well someone copes with ambiguity you created on purpose. Forty-five minutes to an hour is enough for a single, focused problem. Longer sessions start testing stamina instead.
3. Let the candidate choose their language and environment
Let the candidate pick their own language and, where you can manage it, their normal editor. Testing someone's Go ability in a stripped-down browser editor when they've spent five years in a full IDE with autocomplete measures editor familiarity more than the skill you're hiring for. An unfamiliar collaborative editor with no debugger is itself a confound, so use whatever tool gets you closest to how the person actually works day to day, and tell them which one it'll be before the call.
4. Score against a rubric written before the session
Write the rubric before you meet the candidate. Once you're watching them work, it's too late to stay neutral. Decide in advance how much weight goes to process (did they ask clarifying questions, did they test their own code, did they explain tradeoffs out loud) versus completion. Weighing completion too heavily punishes candidates who work carefully and rewards ones who rush. Swett argues the same thing from a different angle: don't make it a race, and judge whether the candidate got anything working at all rather than whether they finished the whole exercise. A rubric fixed before the call also keeps two interviewers scoring the same candidate consistently, instead of each one weighting whatever caught their attention that day.
5. Watch for the specific tells of AI-assisted cheating
A candidate quietly running an AI assistant in a second window still has to defend the code as if they wrote every line and understood why it works. Test for that understanding, because the code alone won't show it. Ask why they added a specific line partway through the session. A candidate leaning on a hidden tool will often stumble on a question about their own code, since they never built the reasoning that produced it. A thread of hiring engineers swapping tells for exactly this problem describes two worth borrowing: ask why a specific line exists and listen for a real answer instead of a fumble, or challenge a correct piece of code as if it were wrong and see whether the candidate defends it or just backs down and changes it at random.
Two more tells worth building into your own process, based on practical experience rather than any published number: latency between a question and an answer that doesn't match the complexity of what you asked, and code that's stylistically inconsistent with itself, clean in one function and clumsy in the next, as if two different people wrote it. Neither proves cheating alone. Both are reasons to slow down and ask a direct follow-up before you move on.
Proxy interviewing, someone else sitting the call in the candidate's place, is a separate risk with its own check. Confirm identity against the resume and any earlier-stage video call before the session starts, keep the camera on for the introduction even if it goes off once screen-sharing begins, and ask one detail-specific question about an earlier stage of your process before you get into code, something only the actual candidate would know. None of this is foolproof, but it raises the cost of substituting someone else for the person you already vetted.
6. Debrief immediately, while the session is fresh
Score the candidate against the rubric within the hour, before the next call or the next task erases the detail. Write down the specific moment that decided your call alongside the number, since a bare score tells the next interviewer nothing about why. If two people sat in on the session, have them score independently before comparing notes, so one strong opinion doesn't anchor the other.
Live coding interview vs. take-home vs. full technical screen
A take-home shows you a finished result with none of the reasoning attached. A live coding interview shows you the reasoning, but only for a narrow slice of work compressed into less than an hour. A full technical screen is the container that holds both, plus a non-technical conversation about communication and past decisions, run in sequence so each stage filters cheaply before the more expensive one runs. The case for having senior engineers run every stage instead of a recruiter or an algorithm is what makes the live session hardest to fake around, since a script can walk a candidate through a rehearsed take-home pitch but not through unscripted questions live.
HighCircl's own screen runs four stages before an offer goes out: background and experience verification, a communication and product-thinking conversation, a take-home project mirroring real work, then a live technical session focused on architectural reasoning, where the candidate defends and extends their own take-home out loud. About 1 in 10 applicants clear all four. The live session that tests architectural judgment is built around that same idea: have the candidate defend choices they already made in their own project rather than solve a problem cold, because someone who copied or generated their submission can usually describe it in general terms but stalls the moment you ask them to change it live.
Common live coding interview mistakes that filter out good engineers
The most common critique of live coding interviews is that they test performance anxiety more than skill. One commenter raised exactly this in the comment thread under Rådell's post, arguing that live coding measures anxiety more than ability and that a system-design discussion plus a review of a candidate's real project would tell you more. He's right about the failure mode. A candidate who freezes under a stranger's gaze on a shared screen isn't necessarily a weaker engineer than one who performs smoothly under manufactured pressure. Some of the best engineers are the worst live performers.
Dropping the live session over this trades one problem for a worse one: you lose the only stage that's genuinely hard to fake with an AI assistant. A better fix keeps the session but changes what it asks for. Have the candidate defend and extend their own take-home project instead of solving an unfamiliar problem cold. Defending your own reasoning under a few clarifying questions is a different kind of pressure than solving a stranger's puzzle on a clock, closer to a design review a senior engineer already sits through regularly, and it correlates with the job itself rather than with public-speaking comfort.
A second common mistake is scoring for correctness alone and calling it objective. A rubric applied only to whether the code runs can't tell you whether the candidate understood every line or generated most of it with an assistant seconds before the call. Weight process signals, the questions asked, the tests run, the tradeoffs explained out loud, as heavily as the final result, or the rubric ends up measuring the wrong thing.
FAQ
How long should a live coding interview last?
Forty-five minutes to an hour, for a single problem scoped to fit that window. Longer sessions test stamina and start overlapping with the deeper technical interview that should come later in your loop. Shorter sessions don't leave room for the follow-up questions that catch AI-generated answers.
Can candidates use AI tools like ChatGPT or Copilot during a live coding interview?
Decide and disclose the policy before the call rather than discovering your position on it live. Some teams allow AI tools openly and score the candidate's judgment about when to use them and when to override a bad suggestion. Others ban them outright and rely on in-session tells, asking why a specific line exists, interrupting with a false correction, to catch quiet use. Either policy works. An undisclosed one doesn't, because you'll end up penalizing one candidate for something another candidate did unchallenged.
Is a live coding interview better than a take-home test?
They test different things, so which one you need depends on what's still unproven about the candidate at that point in your process. A take-home shows whether someone can produce a working solution with nobody watching. A live session shows whether they can explain and defend that solution under a few real questions. Running a take-home first and a live session second, with the live session built around defending the take-home rather than solving something new, gets you both signals for less total interview time than running either stage twice.
What makes a good live coding interview question?
One that's small enough to finish in the time you've allotted, close enough to real work that the candidate's decisions actually matter, and open enough that there's more than one reasonable way to solve it. A question with exactly one correct algorithm rewards memorization. A debugging task, a small feature added to existing code, or a review of a pull request with a subtle bug all work better, because each one forces the candidate to make and explain judgment calls instead of recalling a pattern.