Hiring · July 23, 2026 · 9 min read

Take-home assignment vs live coding: what actually works

Take-home assignment vs live coding: what each format really measures, the candidate-experience and AI-cheating tradeoffs, and the hybrid that beats both.

← Part of The five pillars of hiring: what assessments measure

The take-home assignment vs live coding debate is usually argued from anecdote: someone was burned by a candidate who aced a whiteboard and couldn't ship, or by a beautiful take-home that turned out to be someone else's work. This post is for engineering leaders, hiring managers, and recruiters who own a technical hiring loop and need to choose a format — or defend the one they have — with something better than vibes. You'll get an honest ledger of what each format actually measures, what each one costs candidates, how exposed each is to AI-assisted cheating, and a decision rule for when to use which.

The timing matters because 2026 broke the old assumptions on both sides. Frontier models can complete most unsupervised take-homes end-to-end, which means an unmonitored assignment no longer verifies that the candidate can do the work — only that someone, or something, can. Meanwhile the talent market has shifted toward AI-fluent engineers whose real workflow includes AI tools, so a live session that bans them measures an increasingly artificial skill. And regulators in New York, the EU, Colorado, and Illinois now scrutinize automated hiring tools, so whatever format you pick has to survive an audit.

This applies to any loop that includes a practical exercise — software engineering, data, ML, DevOps, and increasingly analytical and operations roles too. The stakes are concrete: the format you choose determines which candidates drop out, which ones you misjudge, and whether the signal you collect survives contact with AI assistance. The answer, argued below, is that the framing itself is stale — the hybrid of a short sandboxed work sample plus a structured debrief beats both pure formats on nearly every axis.

What does a take-home assignment actually measure?

A well-designed take-home is the closest common format to a true work sample: the candidate works in their own environment, with their own tools, on their own schedule, on a task that resembles the job. That's the case for it, and it's a real one. Decades of selection research put work samples among the most predictive assessment methods precisely because the best predictor of doing the work is a sample of the work.

Done well, a take-home measures things a conversation cannot: how someone structures a problem with time to think, the quality of their code or analysis when nobody is watching them type, how they handle ambiguity in a brief, and how clearly they write up decisions and tradeoffs. For roles where deep, asynchronous work is the job — most engineering roles — those are the right signals.

But the format has failure modes that its advocates tend to wave away:

• It measures available free time as much as skill. A '4-hour' assignment that competitive candidates spend a weekend polishing filters out parents, caregivers, and anyone currently employed.
• Authorship is unverifiable. You are grading an artifact, not a person — and in 2026 the artifact may be largely machine-generated whether or not you allowed it.
• Scope creep is structural. Reviewers reward extra effort, candidates learn this, and the arms race pushes honest time investment far past the stated cap.
• Completion bias creeps in. Finished-and-polished beats thoughtful-but-scoped, even when the latter reflects better engineering judgement.

What does live coding actually measure?

Live coding earns its place by measuring the one thing a take-home cannot: reasoning you can watch. You see how a candidate decomposes a problem in real time, how they respond to hints and pushback, whether they ask clarifying questions or charge ahead, and how they communicate while thinking. For collaborative engineering cultures, that interactive signal is genuinely job-relevant — pairing, debugging together, and design discussions all happen live.

It also has a verification property take-homes lack: the person in the room is unambiguously the person doing the work. That mattered before generative AI; it matters far more now.

The costs are equally real. Coding while being observed and judged is a different cognitive task from coding at work, and a meaningful share of strong engineers underperform under that spotlight while confident interview-optimizers overperform — the format partially measures interview practice, which decays the moment they're hired. Unstructured live sessions also drift with the interviewer: different problems, different hints, different moods, different bars. Without the discipline of a structured interview — same task, same probes, written rubric, independent scoring — a live coding round is closer to a personality read than an assessment.

Take-home assignment vs live coding: the candidate-experience cost

Each format taxes candidates in a different currency, and the tax shapes your funnel before it shapes your signal. Take-homes charge time: multi-hour unpaid work, often requested by several companies at once. Senior candidates with options simply decline — so the format silently selects for people with fewer alternatives, which is the opposite of what you wanted. Live coding charges stress: performance anxiety hits unevenly across people, and a bad experience in a high-pressure session is the story candidates tell publicly.

Neither tax is avoidable entirely, but both are reducible. The candidate experience research is consistent on what helps: tell candidates exactly what to expect, keep the total time proportionate to the role, and close the loop with real feedback. A two-hour capped exercise with a stated rubric and a feedback promise converts dramatically better than an open-ended 'show us your best work' assignment — and generates more comparable signal, too.

Which format is easier to cheat with AI?

Bluntly: the unsupervised take-home is fully exposed. A frontier model can complete a typical CRUD app, data pipeline, or debugging assignment end-to-end, and it will do so in the candidate's voice if asked. Static assignments reused across candidates make it worse — solutions accumulate on GitHub and answer sites, so the test leaks a little more every month it stays in service. AI-detection tools don't rescue the format; they produce false positives that turn into false accusations, which is a worse outcome than the cheating.

Live coding is less exposed but not immune. Second-screen assistants, whisper tools, and coached candidates all exist, and remote sessions are harder to police than in-person ones. The deeper problem is that policing is the wrong frame. In 2026, an engineer who uses AI tools well is more productive than one who doesn't, so a format that treats all AI use as fraud measures the wrong thing. The goal isn't to prevent AI from touching the assessment — it's to make AI use visible and evaluable, which is a design problem, not a surveillance problem. We've written in detail about why per-candidate generation and process visibility beat detection.

When should you use a take-home assignment vs live coding?

If you're choosing between the pure formats, choose on what the job actually rewards and what your funnel can bear:

• Favor a (short, capped) take-home when the role is heavily asynchronous, written communication is core, and you can verify authorship in a follow-up conversation.
• Favor live sessions when collaboration is the job — pairing-heavy teams, staff-level design roles — and you have trained interviewers and a written rubric.
• Favor live sessions when authorship verification matters most: senior hires, security-sensitive roles, fully remote pipelines you've never met in person.
• Avoid take-homes for high-volume top-of-funnel screening; the drop-off compounds and review time doesn't scale.
• Avoid unstructured live coding everywhere. If you can't state the rubric, you're measuring the interviewer.

But treat this as a fallback menu. The better answer for most teams is to stop choosing.

The hybrid that works: short sandboxed work sample + structured debrief

The strongest format we've seen combines the two halves each pure format gets right: candidates do real work with time to think (the take-home's strength), and then explain and extend that work in a live conversation (live coding's strength). The pipeline looks like this:

Designing the work sample

Keep it short — 60 to 120 minutes — and run it in a sandbox: a controlled environment with the tools, data, and scaffolding pre-loaded so no candidate time is burned on setup, and the working process is observable rather than just the final artifact. That observability is what changes the AI equation: instead of guessing whether a model wrote the submission, you can see how the candidate worked, including how they used AI assistance — which, for AI-fluent roles, is itself a skill worth scoring. Generate the task per job description rather than reusing a static assignment, so there is no public solution to find. The sandbox assessment guide covers the design details.

Running the debrief

The debrief is a 30-45 minute structured conversation about the candidate's own submission — not a fresh puzzle. It verifies authorship (people cannot fluently defend work they didn't do), converts the artifact into observable reasoning, and gives anxious candidates a fairer stage: discussing work you've already done is far less threatening than producing it live. Ask every candidate the same categories of questions and score against a written rubric:

1. Walkthrough: "Talk me through your solution. What did you do first, and why?"
2. Tradeoffs: "What did you deliberately leave out given the time cap? What would you do with another day?"
3. Extension: "Requirements just changed: [one concrete change]. What breaks, and how would you handle it?"
4. AI use: "Where did you use AI assistance? Show me a place you accepted its output and a place you rejected it."
5. Failure probe: "What's the weakest part of this submission? Defend or fix it."

Score each on a 1-4 anchored rubric, independently, before discussion.

How do you keep either format fair and compliant?

Whatever format you run, two disciplines protect both fairness and defensibility. First, job-relevance: every task and every rubric line should trace to something the role actually requires — this is the same logic that makes work samples predictive, and it's also your best defense if a selection procedure is ever challenged. Second, consistency: same task difficulty, same time cap, same rubric, same debrief structure for every candidate in the pool. Inconsistency is where both bias and legal exposure live.

If any part of your loop is AI-assisted — generated tasks, automated scoring — the regulatory bar is higher: NYC Local Law 144 requires bias audits and candidate notice for automated employment decision tools, the EU AI Act classifies hiring AI as high-risk, and Colorado and Illinois have their own statutes coming into force. Monitor pass rates by demographic group where you lawfully can, and keep records of what was asked and how it was scored.

Where H-Evaluate fits

H-Evaluate is built around the hybrid this post argues for. It generates work-sample tasks per job description with quality-gated generation — no static shared test library, so there's no accumulated public answer key — and runs them in an AI Sandbox where the candidate's process, including their AI use, is observable and scorable. AI fluency is assessed as a skill rather than policed as fraud, which matches how the work actually gets done in 2026.

The design is compliance-first — built with NYC Local Law 144 and the EU AI Act in view rather than retrofitted — and the output is structured evidence a hiring team can defend: what was asked, why it was job-relevant, and how it was scored. If you're rethinking your technical loop end to end, start with the AI-native hiring overview.

The question was never take-home or live coding. It was always: can you watch real work happen, and can the person in front of you defend it? Any format that answers both is good. Any format that answers neither is theater.