The take-home was, for a long time, the most defensible format in technical hiring. It asked candidates to do something closer to the actual job than a whiteboard puzzle, on their own schedule, without anyone watching over their shoulder. Companies leaned on it because it beat the alternatives on the two things that mattered: it looked like real work, and it didn't require ten people to sync calendars across time zones. That trade held up for years.
It doesn't anymore. The two conditions that made take-homes work — no supervision, no time pressure — are now exactly the conditions an AI assistant needs to complete one convincingly. And the format has a second, older problem AI just made harder to ignore: it asks candidates to donate unpaid hours before anyone on your side has committed to anything. Fix one of those problems and you're still running a broken process. Fixing both means changing the shape of the exercise, not patching the prompt.
What take-homes got right
Give the format its due before you retire it. Two things about the take-home were genuinely good ideas, and any replacement needs to keep them.
The first is realism. A take-home usually asked a candidate to do something that resembled the job — add a feature, fix a bug, build a small service — instead of solving an isolated puzzle with one correct answer. That was a real improvement over algorithm trivia. It tested whether someone could operate in a codebase, not just recall a pattern.
The second is that it didn't require live supervision. A candidate in a different time zone could do it at 11 p.m. on their own schedule instead of blocking out a synchronous slot at a company's convenience. For distributed hiring, that flexibility mattered, and it's worth keeping if you can.
Any format you adopt next should hold onto both: a task that looks like the job, and a process that doesn't force everyone onto the same clock for no reason.
What broke them
Two things changed, and together they take the format from "imperfect but useful" to "actively misleading."
The first is AI completion. A well-specified take-home — a clear task, a bounded scope, a small repo, no live pressure — is close to the ideal input for a coding assistant. Give a model the same prompt over several unsupervised hours and it will produce a plausible, working solution. A candidate doesn't need to understand the codebase to submit something that clears your rubric; they need to paste the prompt, skim the diff, rename a few variables, and turn it in. You can't tell, from the artifact alone, whether you're looking at their engineering or the model's. The take-home's lack of supervision — the thing that made it convenient — is the same thing that makes it gameable now.
The second is the unpaid-hours problem, and it predates AI, but AI made it worse. A four-to-eight-hour take-home was always a real ask before either side had committed to anything. Strong candidates with options increasingly decline on principle, which selects against the candidates with the most leverage — usually your strongest ones. The ones who still do it are disproportionately either the least busy elsewhere, or the most tempted to let a model do the sinking for them. The format increasingly filters for patience and access to a good assistant, not for engineering skill.
Both problems trace back to the same root: nobody's watching, and nobody's paying. Fix the supervision and you fix AI completion. Fix the time cost and you fix drop-off. The four alternatives below each pick a different point on that trade-off — see our fuller comparison of take-homes against live, defended screens if you want the format-by-format breakdown.
Alternative 1: a short, supervised session instead of a long solo one
The most direct fix is to shrink the take-home into something you can actually watch. Instead of four to eight unsupervised hours, run a scheduled ninety-minute block: a real, small codebase, a scoped task, an AI assistant explicitly allowed, and either an interviewer present for the whole session or a screen recording reviewed afterward with a short live defense.
This keeps the realism — it's still a real task in a real codebase — and it removes the two failure modes at once. Supervision (live or recorded) removes anonymous AI completion, because you can see whether the candidate is reading and directing the tool or just waiting on it. And bounding the session to ninety scheduled minutes, rather than an open-ended evening, removes most of the unpaid-hours objection; it reads as an interview, not as homework.
The trade-off is that ninety minutes is a shorter task than a take-home allows, so the scope has to be tight — one bug, one small feature, not a mini-project. That's a feature, not a bug: a tightly scoped task is also easier to grade consistently across candidates.
Alternative 2: have them review a real PR, not write one
Most engineering work is reading code, not writing it from a blank file — reviewing a teammate's change, catching a risk before it merges, deciding whether a design holds up. Take-homes almost never test that, because they're built around producing a diff. Flip it: give the candidate a real or realistic pull request — ideally one with a genuine, subtle problem in it, like a race condition or a change that breaks an assumption elsewhere in the codebase — and have them review it the way they would on the job. Leave comments, flag the risk, propose an alternative.
This is fast — thirty to forty-five minutes, easily supervised live or over a short recorded walkthrough — and it exercises judgment directly instead of asking you to infer it from a finished artifact. Producing a diff from a prompt is exactly what current models are good at; defending a specific critique of specific lines under a live follow-up question is a different, more exposed kind of output, because the candidate can't hide behind code that merely runs.
Alternative 3: extend a codebase live, together
Where alternative one can be solo-and-recorded, this one is deliberately synchronous the whole way through: an interviewer and candidate share a small, unfamiliar-to-the-candidate codebase and add a real feature together, live, for forty-five minutes to an hour, AI assistant open the entire time.
The realism is as high as it gets — closer to actual pairing than any other format here — and because the interviewer is watching in real time, there's no artifact to launder afterward. You see the candidate read the existing code, decide where the change belongs, and either accept or push back on what the assistant hands them, all in the moment. It's the most expensive alternative here in interviewer time, which is why it's usually a later round, not a high-volume first pass.
Alternative 4: a paid trial task
For senior hires, or any role where you can afford lower volume, the cleanest fix for the unpaid-hours problem is to stop pretending it isn't a cost: pay for it. Treat the exercise like a short contracting engagement — a real, useful, bounded piece of work, paid at a fair rate, done over a few days on the candidate's own schedule, followed by a live review call where they walk you through what they built and why.
Paying doesn't solve AI completion by itself, but it changes the incentive: candidates who'd walk away from unpaid homework will do a paid, respected engagement, and a live review afterward still exposes anyone who can't account for their own decisions. It's the highest-fidelity option here and the most expensive per candidate, which is why it belongs later in the funnel, not at the top of it.
Which one to run, by role, seniority, and volume
None of these four replace a take-home one-for-one across every role. Match the format to what you're actually optimizing for.
High-volume, early-career roles want cheap and fast: the short supervised session or the PR review, both under an hour and consistent to grade across a large pool. Mid-level roles, hiring fewer people and wanting a deeper read, fit the live extend-the-codebase session — expensive per candidate, but you're running far fewer of them. Senior, staff, and lead roles, where a bad hire is costly and the pool is small, justify the paid trial task.
If your current gate is a closed algorithm round rather than a take-home, the underlying problem is the same one degrading it — see our piece on whether leetcode interviews are still worth running for that side of the argument.
We built Chiron around the shape of the first and third alternatives here — a real small codebase, an AI assistant allowed throughout, and a scored live defense — because that combination is the one that scales without asking anyone to donate an unpaid evening; see our AI coding assessment if you want the packaged version, or pricing for the details. But the format matters more than who builds it. Whatever you run next, keep the two things the take-home got right — realism and respect for the candidate's time — and stop asking a format built for a world without AI assistants to keep doing a job it can no longer do.