The take-home test is dead. Engineers killed it, AI buried it.

The take-home test died twice.

The first death was slow, and engineers did it. Somewhere around the time every mid-size company started asking for "a small project, should only take 3–4 hours" (it took nine), senior candidates started declining. Not because they couldn't do the work - because the deal was insulting. Ten applications times nine unpaid hours is a part-time job with a rejection rate. The candidates you most wanted were exactly the ones with the leverage to say no. Take-homes became a filter that selected for people who couldn't refuse them.

The second death was fast, and AI did it. Today a take-home is a prompt. Any candidate with a frontier model produces a clean, tested, well-documented submission in twenty minutes. You cannot tell who wrote it, and - this is the uncomfortable part - it no longer matters who wrote it, because the artifact was only ever a proxy for a skill, and the proxy just stopped correlating.

The detection dead end

The industry's first response was predictable: AI detection. Proctoring, keystroke analysis, webcam requirements, plagiarism scores for code.

This is an arms race, and the assessment vendor loses it every time. Detection models trail generation models by definition, the detector is always trained on last generation's output, and the candidate is always holding this one. Every false positive burns a real candidate; every proctoring requirement tells your best candidates you don't trust them before you've met them. You are paying money to make your funnel worse.

There's a quieter cost too. Detection reframes the interview as an integrity problem, and once that framing is in the room it changes what you look at. You start grading whether the work is authentic instead of whether it's good, and those are not the same question, a candidate can write every line themselves and still have no idea why the thing works.

And the premise is wrong. Your engineers use AI at work. Today. On real tickets. An interview that bans AI is a simulation of a job that no longer exists.

What the take-home was actually for

Strip away the format and the take-home was trying to measure something real: can this person do unsupervised work on an unfamiliar problem? That's still worth measuring. The format failed, not the question.

So test it directly. Put the candidate in front of a system that is genuinely broken - not a toy repo, a live environment with a real fault - and watch the process:

• What do they look at first?
• Do they form hypotheses or flail?
• When they're wrong, how fast do they notice?
• What did they break along the way, and did they clean it up?
• And yes: how well do they use AI when it's allowed? Did they paste the right context? Did they catch the model's wrong suggestion, or apply it blindly?

None of that can be outsourced to a model, because it includes the model. The skill being measured is the driving, not the typing.

This is also the only version of the question that survives the next model release. If your assessment breaks every time a lab ships a better model, you weren't measuring engineering, you were measuring access.

Alternatives to take-home tests, honestly compared

The replacement has to satisfy three constraints at once: it has to be short enough that good candidates accept it, it has to be resistant to being handed to a model wholesale, and it has to produce something a hiring manager will actually review. Most of the usual options fail at least one.

Live pair-programming is genuinely good and underrated, it's the closest thing to a conversation with a colleague. Its weakness is that it grades the person who performs well while being watched, which is a real skill but not the one you're hiring for at 3 AM.

The live-incident format wins for infrastructure roles for a narrow reason: the environment answers back. A model can tell a candidate what to type, but the pods still have to become Ready, and the transcript shows which of the two was leading. That's also why scenario questions beat definition questions even in a plain conversational interview, the ones with a wrong turn built into them are the ones that separate candidates.

What to actually watch

If you switch formats and keep grading the outcome, you've changed the packaging and nothing else. The outcome is the least interesting thing in the transcript, plenty of candidates get there, and some of them leave wreckage behind on the way. What's worth reading:

• Order of operations. The first three commands tell you whether someone has a method or a memory.
• Recovery from a wrong hypothesis. Everyone guesses wrong. The gap is in how long they stay committed to it.
• Blast radius. What did they disable, delete, or restart to make the symptom go away, and did they put it back?
• Verification. Did they confirm the fix, or did they declare victory when the red text stopped?

None of those need a proctor, and none of them care whether an AI was in the room.

The deal is better too

A 45-minute live incident respects the candidate's time in a way "3–4 hours" never did. It produces a replay a hiring manager can actually watch instead of a zip file nobody reviews properly. And it gives candidates something take-homes never did: the fun kind of hard. Engineers who'd decline your homework will fight a broken cluster for the sport of it.

The take-home is dead. Don't resurrect it with proctoring. Replace it with the job.

FAQ

Are take-home tests still worth using in 2026? Rarely, and not as a filter. A take-home now measures who was willing to spend the evening, not who can do the work, and it can be completed by a model in a fraction of the stated time. If you keep one, make it paid, make it short, and treat the follow-up conversation about the submission as the actual assessment.

What is the best alternative to a take-home test? For infrastructure and SRE roles, a short live incident on a real broken environment: it's under an hour, it can't be pre-solved from a leaked prompt, and it produces a replay a hiring manager can review. For other roles, a scoped live work sample with the candidate driving beats both the whiteboard and the homework.

Should candidates be allowed to use AI in interviews? Yes, if they use it at work. Banning it tests a job nobody has any more, and enforcing the ban costs you candidates through false accusations. Allow it and grade the driving, whether the candidate gave the model the right context, and whether they caught it when it was confidently wrong.

Doesn't a live interview disadvantage nervous candidates? Some, which is why the format matters more than the label. Removing the audience helps: a recorded solo session with no one watching over the shoulder is far less pressured than a live pair-programming call, and it still can't be outsourced. Give the context up front, allow notes and search, and grade process rather than speed.