AI Killed the Take-Home Coding Test. Here's What Replaced It

I had eight take-home submissions open in tabs and no honest way to rank them.

Every one had a README with a Setup section. Every one had tests. Every one had a services/ folder, a custom error class, dependency injection, and a thoughtful paragraph about trade-offs I never asked about. Two years earlier, any single one of those would have been an instant advance. Now it was the median. The take-home coding test hadn't gotten harder or easier. It had stopped measuring anything.

TL;DR

• The take-home coding test broke not because candidates cheat, but because AI compressed everyone into the same top score. A rubric where 90% of submissions land in the top band is a rubric that ranks nobody.
• Detection is a dead end. Teams that pivoted to "prove you didn't use AI" burned goodwill and still couldn't tell.
• The replacement is the extension round: you submit code, then live, on a call, you add a feature to it. Ownership shows up in seconds and can't be pre-generated.
• Other rounds that survived: reviewing a deliberately flawed PR, debugging a failing repo, and walking through code you actually shipped.
• As a candidate, the new bar isn't producing code. It's defending code. A rough submission you can defend now beats a polished one you can't.

Why did the take-home coding test stop working?

Because take-homes measured output, and output got cheap. A take-home coding test was never really testing whether you could write a REST endpoint. It was a proxy: someone willing to spend six careful hours, who structures a project sanely and writes tests unprompted, is probably a solid engineer. The proxy worked because effort and skill were correlated.

AI severed that correlation. Structure, tests, README, error handling, and a trade-offs section are now the cheapest part of the deliverable. They arrive by default.

The failure mode isn't dramatic. It's statistical. Score dispersion collapses. When I look back at my own review notes, the spread between the strongest and weakest submission used to be huge; now the top two-thirds are separated by taste, not capability. And when a rubric can't separate people, hiring managers fall back to whatever else is lying around: school name, company logos, how the README is worded. Every one of those is worse than the thing it replaced.

There's a second, quieter failure. Take-homes got longer. When submissions all look great, the natural reaction is to raise the bar: more features, more edge cases, more polish. So the cost to the candidate went up while the information to the company went down. That's the worst possible trade, and it lands hardest on people with kids, second jobs, or a current employer.

Should companies just ban AI on take-homes?

No, and the teams that tried mostly wasted a quarter finding out. "Please complete this without AI assistance" is an honor system on a task nobody watches, competing against a tool that is open in the next tab and genuinely useful. You are asking people to voluntarily perform worse than their peers for the privilege of a second-round call.

Then comes the detection arms race: commit-timeline forensics, stylometry, invasive proctoring. I've watched teams spend more energy building an accusation pipeline than a signal. Even when they were probably right, "probably" is not a thing you can put in a hiring decision without poisoning the room.

The useful reframe: stop asking did AI write this, start asking does it matter. On a real team, an engineer using AI to produce a working service is not a problem. An engineer who can't explain, extend, or debug what they shipped is a very expensive problem. That second thing is measurable. So measure that.

What replaced the take-home? The four rounds that survived

Ranked by how much signal they give per minute of everyone's time.

1. The extension round. Keep the take-home, but cut it to 90 minutes and make it explicitly AI-allowed. Then, live on a call, hand over one new requirement against the code they submitted. "Right now the rate limiter is per-process. Make it work across three instances." Or: "Add pagination to this endpoint without breaking the existing tests."

Twenty minutes of this outranks six hours of submission review. You're watching someone navigate a codebase they claim as theirs. Where do they put the change? Do they know which file holds the config? When their own test suite goes red, do they read the failure or start guessing? Someone who genuinely built it moves like they're in their own kitchen. Someone who isn't oriented opens files by search and reads them as if for the first time. I'm not describing a gotcha. I'm describing the difference between owning code and having code.

2. The bad-PR review. Give the candidate a 200-line pull request 20 minutes before the call. Plant three things: a real bug (an off-by-one in a boundary check, a swallowed exception, a race on shared state), one design smell that isn't a bug, and one thing that looks wrong but is actually fine and intentional.

Then ask what they'd block on. This is the round I'd keep if I could keep only one. Reading, prioritizing, and pushing back on code is what senior work has always been, and it's a larger share of the job now that generating a first draft is nearly free. It also surfaces the failure mode nobody screens for: the candidate who flags all nine style nits and misses the race condition. Bonus signal in how they'd word the comment. "This is wrong" versus "what happens if two requests hit this at once?" tells you exactly what code review with them feels like on a bad Thursday.

3. The debug round. A repo, a failing test or a wrong output, 30 minutes. Let them use whatever tools they want, including a model. The interesting part isn't the fix, it's the search strategy: do they form a hypothesis and test it, or do they change lines until the red goes away? AI has made this round more discriminating, not less. Watching someone steer a model through an unfamiliar bug tells you more about their thinking than watching them type. Great engineers ask it narrow, checkable questions. Everyone else pastes the whole stack trace and hopes.

4. "Walk me through something you shipped." Their code, their repo, their screen, no prep expected. Ask why three specific decisions were made. Ask what they'd do differently. Ask what broke in production. This round is unfakeable in a way no synthetic exercise is, because the followups go anywhere and real context has infinite depth. Its weakness is access: not everyone can show proprietary code, and someone straight out of school has less to draw from. So it belongs in the mix, not alone.

What should you do as a candidate now?

Assume every submission you make will be discussed live. That single assumption changes your prep more than any algorithm grinding.

• Use AI, then audit. Take the generated code and go through it line by line until you can justify each one. If a chunk is there because it appeared and you don't understand it, delete it. Undefendable code is now a liability, not padding.
• Cut scope on purpose. Ship four solid features instead of nine shaky ones, and write down what you deliberately skipped and why. "I didn't add caching because at this scale it's premature" is a senior sentence. Interviewers notice.
• Rehearse the extension. Before you submit, ask yourself what you'd add next, and actually add it in a scratch branch. You'll find the seams in your own design, which is exactly the conversation the interview is going to have.
• Know your own repo cold. Where's the config, what does the test command do, which file would you touch first. Fumbling here reads far worse than any missing feature.
• Say what you used. "I generated the scaffolding, then rewrote the retry logic because the first version retried on 4xx" is a strong answer. It shows tooling fluency and judgment at once. Pretending you hand-typed everything is the risky play, and it buys you nothing.

Is the take-home coding test dead?

The eight-hour, unpaid, do-it-alone, no-AI-allowed take-home coding test is dead, and it deserved it. It measured effort at a moment when effort stopped predicting skill, and everyone kept scoring it long after the scores went flat. What replaced it is smaller and more honest: a short AI-allowed build, followed by a live round where you extend, defend, or debug the thing in front of a human. The question moved from "can you produce this code?" to "do you own this code?" That's a harder question to fake, a faster one to answer, and frankly a better description of the job. If you're preparing for interviews right now, stop optimizing your submission and start optimizing your ability to talk about it under pressure.