Every few months someone publishes a piece titled "take-homes are dead" or "take-homes are broken" and the comments under it fill with engineers sharing stories of the six-hour unpaid project they bailed on last year. The frustration is real. The diagnosis is usually wrong.
Take-home projects as they're currently run are broken in four specific, fixable ways. The underlying idea — give a candidate an async problem and read what they produce — is still probably the best single signal any interview round generates. The shape isn't the problem. The packaging is.
Where the take-home actually goes wrong
They're asymmetric. A typical modern take-home asks for four to eight hours of real work from a candidate who hasn't been offered the job. The company's engineers then review the submission in fifteen minutes, often with only half their attention. The candidate invested the entire weekend; the team invests the length of a coffee break. The exchange isn't fair, and the candidates most able to afford that kind of asymmetry are the ones with the most free time, which isn't the filter anyone actually wants.
The AI rule is a shrug. Most take-home briefs contain a paragraph about AI that was written a year or two ago and hasn't been revisited since. "Please use AI where helpful" or "we'd prefer you didn't use AI for this exercise" — neither is enforced, neither is scored for, and the candidate has to guess which version the team actually meant. Submissions come back varying wildly in how much the tool contributed, and the team has no way to compare them like for like.
Nobody reviews them properly. The take-home is usually graded by whichever engineer has a free slot that week. There's rarely a rubric specific to the exercise, and there's rarely a second reader. Two equally strong submissions can end up with very different outcomes depending on which reviewer picked them up. Calibration is basically impossible.
The follow-up goes to waste. When the submission does make it through, the follow-up interview usually opens with "walk me through your solution." The candidate has prepared for that question, produces a tidy summary of their work, and the team learns almost nothing they didn't already know from reading the submission. The follow-up is where a take-home earns its keep, and most teams skip that work.
None of these are problems with the idea of an async exercise. They're problems with how teams have let the exercise drift.
The underlying shape is still right
Strip away the asymmetry, the AI ambiguity, the uneven grading, and the wasted follow-up. What's left is this: a candidate works through a realistic problem on their own time, produces an artefact and some reasoning about it, and then has a structured conversation with the hiring team about the artefact. That shape is the single best signal most interview processes generate. You get framing, you get trade-offs, you get the candidate's voice, and you don't pay for it with performance anxiety.
The reason it keeps getting proposed and keeps getting adopted is that it works. The reason it keeps getting complained about is that it's easy to implement badly.
What fixing the packaging looks like
A take-home that holds up in 2026 looks different from the one most teams are sending out now.
It's short. Ninety minutes, not a weekend. Beyond two hours of real work, the exercise starts to measure free time rather than engineering judgement. If you can't scope your exercise to fit, it's probably trying to do the work of two rounds at once.
It's explicit about AI. Either the candidate uses AI and you collect the transcript, or they don't and you say so clearly. No middle ground, no paragraph of vague preference. The position is part of the brief.
It asks for reasoning, not just artefact. The core deliverable is a short written explanation of the choices the candidate made, with the code or the design as supporting evidence. The reasoning is what you read first.
It has a scheduled reader with a plan. The person who grades the submission is named in advance and is the same person running the follow-up. They read the submission with the follow-up in mind — marking questions, picking openings, deciding what to ask about live.
That's the fix. Not a different shape; the same shape, packaged like you mean it.
What CriticCode is trying to do
The reason CriticCode exists is that even teams that agree with all of the above find the packaging hard. Collecting a transcript, enforcing the time budget, giving the candidate an AI collaborator that plays nicely with the brief, producing a submission that a hiring manager can actually use — the individual pieces are small, but doing them by hand every time is the reason take-homes drift back into the broken shape.
It's entirely possible to run this kind of round without a dedicated tool. Lots of teams do, well. The tool just lowers the floor on how much work it takes to keep doing it properly.
The practical move
If your current take-home is broken by any of the four failure modes above, the useful experiment isn't to drop the round. It's to scope a two-hour version, clarify the AI policy, assign one named reader, and have that reader run the follow-up. Most of the complaints you hear about take-homes go away when the packaging is tight. The shape underneath was never the problem.