How to run a live coding interview

To run a good live coding interview, prepare one realistic problem you have solved yourself, spend the first few minutes making the candidate comfortable, then let them drive while you watch how they think. Keep the clock as a guide rather than a guillotine, and have every interviewer write their verdict alone, right after the session, before anyone compares notes.

Prepare the problem before the day

The problem matters more than anything you say in the room. A good one looks like the work the person would do in the job, fits comfortably in the time, and has more than one way to make progress.

Pick something you've solved yourself

Run through the task on a clean copy, with a timer, before any candidate sees it. If it takes you 30 minutes, it will take a candidate under pressure closer to 60. Cut scope until your own time is about half the session.

Make it real, not a puzzle

A small bug in a working service, a missing endpoint, or a slow query tells you far more than a trick algorithm. Candidates should spend their time reasoning about code, not decoding the question.

Plan extensions, not a single finish line

Write down two or three follow-ups in rising difficulty, such as "now handle concurrent requests" or "how would you test this?". Strong candidates reach them; everyone else still finishes something. Nobody should leave feeling they failed because they didn't reach step five.

Write the brief down

Put the task, the constraints and what "done" looks like in writing. Spoken instructions get misheard, and a written brief means every candidate starts from the same place.

What should happen in the first five minutes?

The first minutes set how the rest of the hour goes. Use them to lower stress, not to test.

1. Introduce everyone on the call and what they do.
2. Explain the format: how long you have, that you care about how they work more than whether they finish, and that asking questions is expected.
3. Say what tools are allowed: their own documentation searches, the terminal, and AI agents if you have them on.
4. Give them a minute to read the brief and the code, and ask what's unclear.

Check that the environment works before the clock matters. A dependency install failing in minute one is your problem, not theirs.

Let the candidate drive

The candidate types; you watch and listen. Resist the urge to take over the keyboard or dictate the next line.

• Ask them to think out loud. You learn more from "I'm checking whether this is called anywhere else" than from the final diff.
• Answer questions like a colleague would. If they ask about the codebase, tell them. Withholding context you'd give a new hire just tests guessing.
• Nudge when they're stuck, not when they're slow. Give them a few minutes on a wrong path. If it's going nowhere, a small hint ("what does the log say?") keeps the session useful.
• Don't fill silence. Quiet often means thinking. Ask before you interrupt.

Use the shared view on purpose

When you need to point at something, follow their view rather than asking them to scroll. A shared whiteboard helps for the design part of a problem: sketching data flow or an API shape before writing code is a skill worth seeing, and it gives quieter candidates a way to show their reasoning.

Should you allow AI in a live coding interview?

Decide before the interview, tell the candidate in the invitation, and apply the same rule to everyone.

Turn agents on when the job involves working with them. Then the signal is how the candidate briefs the agent, whether they read and question its output, and whether they test what it wrote. Turn them off when you want to see how someone reasons through unfamiliar code on their own, or when the task is small enough that an agent would solve it in one prompt.

Either way, the task has to fit the rule. A problem an agent finishes in a minute tells you nothing with AI on. For more on this, see Claude Code in technical interviews.

How long should a live coding interview be?

Sixty minutes is a sensible default: five to settle in, 40 to 45 on the problem, and ten for the candidate's questions. Go to 90 for a larger codebase. Longer than that and you measure stamina.

Treat the time as a guide. If the candidate is a few minutes from finishing something meaningful, give them the minutes. Always leave time at the end for their questions; that part matters to them as much as the coding matters to you.

Write verdicts independently, right after

Memory fades within hours, and the first opinion voiced in a debrief anchors everyone else's. So:

• Each interviewer records a verdict and a short note before talking to the others or reading their verdicts.
• Write down what you observed ("added a test before changing the parser"), not adjectives ("smart").
• Judge against what you agreed before the interview, not against the last candidate.
• If the panel disagrees, talk it through, then let one person make and record the call.

For reviewing submitted work after the fact, see How to review take-home assignments fairly.

Doing this in Kendor

In Kendor, a live coding interview is a saved setup that you invite candidates to. Each session opens a fresh copy of the code in a shared sandbox, with a built-in video call. More detail in Start a live coding interview.

Set it up once

Open Live coding in the sidebar and choose New live coding interview. Then fill in:

• Code: import a repository, or start blank or from a template. Every session opens a fresh copy.
• Brief for the candidate: shown in the room's Prompt tab.
• AI assistants in the terminal: Claude Code and Codex, on your organization's API keys.
• Default session length (minutes): 60 if you leave it empty.
• Interviewers: added to every session's panel, and each gives a verdict.

Invite a candidate

Choose Invite. Pick Start now to go straight into the room and share the link with Copy link, or Schedule to set a date and send the invitation by email. You can change the Length (minutes) and flip Claude Code and Codex in the terminal for this one session. Candidate details are optional when you start now: the candidate can add them when they join.

In the room

The candidate checks their camera and asks to join; you choose Admit. The room has two views, Whiteboard and Code. Interviewers move the room between them; the candidate follows.

• On the whiteboard, the Follow chip (for example Follow Ada) keeps your view on theirs.
• On the code, open a person's avatar in the top bar and choose Follow with their name to mirror their editor.
• The AI on / AI off switch in the top bar turns agents on or off for everyone in the session.
• The clock counts against the session length. Nothing stops when it runs out; +15 min adds time.
• Edit brief changes the task text mid-session, and Chat sits in the side panel.

When terminals, requests from the Requests panel and AI agent chats are recorded for the hiring team, the candidate sees a notice saying so in the lobby. The video call itself is never recorded. See In the room.

After the session

Choose End session. The sandbox shuts down for everyone, and the final code, whiteboard and recordings stay with the session. Open its result page from the live coding interview's Sessions list with View result. It has the Final code, Terminal, AI agents, Requests, Whiteboard and Comments tabs.

Each interviewer picks a Recommendation (Strong yes, Lean yes, Lean no or Strong no) with an optional note, then someone records the Decision: Advance or Reject. Everyone's verdicts show on the same card, so write yours before you look. See Interviewer verdicts.