Take-Home Coding Assignments Are Dying. The Replacement Isn't Better Cheating Detection.

The stat that killed the take-home coding assignment

Something shifted in technical hiring inside about six months. Between June and December 2025, the share of candidates flagged for AI-assisted cheating across interview loops rose from roughly 15% to 35%, and on technical roles specifically that figure now sits close to 48%, per data reported by assessment vendors tracking their own screening pipelines. That is not a rounding change in how strict reviewers got. It is close to half of technical candidates.

It also is not spread evenly. Junior candidates are flagged at nearly twice the rate of senior ones. None of this means half of engineers are secretly incapable. It means the take-home coding assignment, the asynchronous, unobserved exercise most engineering teams have leaned on for a decade, stopped doing the one thing it was built to do.

Detection is a fight you cannot win

The obvious first response was to get better at catching it. Assessment platforms added timing analysis: burst typing, paste events, keystroke cadence that looks too smooth for someone actually thinking through a problem. For a while, it worked.

Then tools built specifically to defeat those heuristics showed up. Typing simulators that insert realistic pauses, backspaces and hesitation are now a normal part of the AI-assisted-interview toolkit, sold openly as a way to pass detectors tuned to flag unnaturally clean submissions. Every signal a vendor ships becomes a spec for the next evasion tool a week later.

That is not a hiring problem you solve with a better filter. It is a race that gets cheaper for the candidate to win every quarter model capability improves, and hiring teams are not going to out-spend that curve.

What the take-home coding assignment actually tested

Strip out the cheating conversation for a moment and the format has a design problem of its own. What was it actually measuring?

For most of the last decade, the honest answer was: whether someone could sit alone, unobserved, for two to six hours, and produce a working, reasonably clean solution to a scoped problem. That correlated with on-the-job ability for a specific reason. Writing correct code from a blank file, unsupervised, with no one to ask, took real skill: parsing an ambiguous spec, structuring a solution, inventing your own edge cases and debugging against them.

AI made that specific skill cheap. Not free, since a candidate still has to read, adapt and stitch together whatever a model produces. But cheap enough that the take-home stopped measuring the scarce part. A candidate who prompts well and has decent taste in output will submit something that looks like strong independent work, whether or not they wrote a line of it themselves. And a candidate who genuinely wrote every line without touching an assistant is now competing against submissions built in a fraction of the time. At that point, even the honest submissions are not comparable to each other any more.

The junior gap is the real alarm

Here is the part that should worry a hiring manager more than the cheating itself: junior candidates are flagged at close to twice the rate of senior ones.

Read that as a training and incentive story, not only an ethics one. Junior candidates have less real production experience to lean on, which makes the pull toward closing the gap with a model stronger. A single coding interview also matters more to someone earlier in their career, and they are less likely to have already been through a hiring loop that assumes AI use and adjusts what it grades for, unlike more senior candidates who have had more cycles to calibrate what a given company actually wants to see.

The effect compounds down the funnel. If a take-home is the first filter a junior candidate hits, and it disproportionately screens out honest applicants in favour of ones with a slicker AI workflow, that funnel is no longer measuring engineering potential at the entry level. It is measuring who is best at producing a plausible submission fast. Those are different skills, and only one of them is what most teams believe they are hiring for.

It also shows up later, once the honest hire and the AI-assisted hire both land on a team. The gap that a take-home was supposed to catch before the offer letter now surfaces in the first few sprints instead, in the form of a new hire who can produce a pull request but struggles to explain why it works when a senior engineer asks a follow-up question. By then it is a performance-management problem instead of a hiring one, and it costs a lot more to unwind.

Why banning AI outright does not fix it either

The instinctive counter-move, telling candidates flatly not to use AI on the take-home, mostly just moves the dishonesty rather than removing it. A rule that is unenforceable at the point of submission is a rule that only the honest candidates follow, which recreates the exact problem it was meant to solve: the applicants most willing to break an instruction you cannot police end up with an edge over the ones who complied.

Some teams tried the opposite fix instead: banning take-homes altogether and going back to in-person algorithm rounds. That solves the AI problem by discarding a decade of hard-won lessons about why whiteboard algorithm tests were a poor predictor of job performance in the first place. It trades one bad signal for a worse one, at the cost of candidate goodwill nobody has to spend any more in a market where good engineers have options.

Three replacements, and what each one trades away

None of this means going back to five rounds of whiteboard algorithms. Teams that have actually gotten signal back generally did one of three things, and each comes with a real cost.

None of these three is free. The live formats cost interviewer time that the asynchronous take-home never did, which is exactly why take-homes got popular in the first place. But interviewer time was always going to be the price of a signal AI cannot fake, once producing code stopped being the bottleneck.

What actually survives: grading judgement, not production

The skill that is genuinely scarce right now is not writing code. It is knowing which code is worth writing, spotting the bug a model glossed over, and defending a trade-off out loud to someone who is going to push back on it. Every format replacing the take-home, live pairing, a defence of your own submission, scoped debugging under observation, is really just a different way of grading that judgement instead of grading output.

Engineering teams that redesign their loop around that distinction will not need a better cheating detector. They will have removed the thing cheating was actually good at gaming.