The take-home assignment is dead. Mostly.

The take-home assignment had a good run. From roughly 2012 to 2023, it was the least-bad answer to a real problem: how do you assess engineering skill without putting someone on the spot under artificial constraints? Whiteboard interviews were broken in obvious ways: they test a specific genre of memorised algorithm, under social pressure, with no access to the tools engineers actually use. The take-home was a plausible correction: work in your own environment, use your own setup, take a reasonable amount of time. The implicit contract was clean: we are going to see what you can do working alone. That contract does not hold anymore.

What take-home assignments were solving for

The case for take-homes was never really about take-homes. It was about measuring unassisted engineering capability in a realistic environment. The unassisted part mattered. It was what the signal was built on.. Given enough time, the right tools, and no one watching, can this person build something that works?

This was a reasonable proxy for job performance in 2015 or 2016. The gap between senior and junior engineers showed up clearly in the output. Someone who had internalised good patterns wrote a cleaner solution than someone who had not, even with reference materials available. Interviewers could calibrate: this code is confident and idiomatic; that code is functional but shows a gap in understanding state management, or error handling, or data modelling.

The format also addressed a real fairness problem. Take-homes reduced the performance-anxiety tax that whiteboard interviews impose on candidates from non-traditional backgrounds, neurodivergent candidates, or anyone who does not perform well under explicit observation. That mattered, and still does.

The tool that changed the signal

GitHub Copilot launched in 2021. Cursor, Cody, and a dozen close competitors followed in the next two years. By late 2024, AI coding tools were standard at most SaaS companies, not just available but part of the daily engineering workflow. By 2026, the question is not whether engineers use these tools; it is which ones they use and how well.

This matters for take-homes in a specific, practical way. A 4-hour coding assignment can now be completed in 45 minutes if the scope is anything typical — a REST API, a data processing script, a CRUD interface with authentication. Not by some shortcut, but by working the way engineers at most companies work every day.

If you give a candidate four hours for something a capable engineer with AI tools finishes in 45 minutes, you have created a waiting game. The remaining three hours are spent polishing, adding tests that were not requested, wondering what the interviewer actually wanted, and second-guessing architecture choices that took 30 minutes to land on. This is not signal. It is noise in a longer container.

What you are measuring in 2026

The uncomfortable reality is that most take-home assignments are now primarily measuring how well a candidate uses AI coding tools, whether the assignment was designed to do that or not.

This is not entirely bad. AI tool use is a genuine skill. Engineers who consistently get high-quality output from AI tools do something different from those who do not: they break problems into smaller, well-specified parts; they spot model hallucinations in generated code faster; they iterate on prompts and outputs rather than accepting the first result. These are valuable attributes in 2026.

But the rubric was calibrated for unassisted coding. The time estimates, the good-versus-great judgments the reviewer applies, the benchmarks against which a submission is scored. All of it was built on the assumption that what you are looking at is the candidate's work without a capable coding partner. That assumption is gone.

You end up in an ambiguous middle: you cannot reliably tell whether you are looking at an engineer who deeply understands what they built, or one who assembled it plausibly. Because the rubric was not designed for this distinction, different interviewers calibrate differently, which adds interviewer variance on top of tool variance. The signal deteriorates from both directions.

The formats that still carry signal

What is replacing the take-home is not a single new format. It is a set of exercises that test understanding rather than output. These are formats where AI assistance cannot short-circuit what you are actually measuring.

Code review sessions

Give the candidate a realistic pull request — 150 to 300 lines, in a real-enough codebase, with genuine issues embedded in it. A subtle logic error. An N+1 query pattern. A missing edge case. An interface that is going to be painful to extend. Give them 30 minutes to review and leave comments, then spend 15 minutes discussing what they found.

This tests reading code in context, not generating it. AI tools do not meaningfully help because the question is not 'produce something' — it is 'read this specific code and say something accurate about it.' The signal comes from what they catch, what they miss, and what they are honest about being unsure of. An interviewer who says 'I am not sure this is a problem but I would raise it' is more informative than a confident list that misses the main issue.

Architecture design conversations

Present a scenario and have a conversation. No coding. A document processing pipeline that needs to handle 10,000 items per day with a specific access pattern. A multi-tenant SaaS that is starting to have per-tenant performance variance. A sync mechanism between two systems with different consistency requirements. Ask them to walk through how they would approach it.

What you are looking for: do they ask the right clarifying questions? Do they identify where the hard parts actually are? Do they make principled tradeoffs, or do they reach for the first tool that comes to mind? Do they update their answer when you add new information? There is no single correct answer. The reasoning process is what you are evaluating.

Live debugging with real tools

Give a candidate access to a realistic codebase with a real bug. Let them use whatever tools they would normally use — including AI coding tools. Sit with them.

This is close to pair programming, and it tests the actual job. You see how they navigate an unfamiliar codebase. Whether they form hypotheses and test them, or try things at random. How they use AI tools — which is the signal you actually want in 2026. Whether they trust their diagnostic output or verify it. An hour of this tells you more than four hours of a solo build.

A note on length

Whatever format you use, the highest-return change most teams can make is cutting the time commitment in half.

A 4-hour take-home is not two hours of extra signal. Beyond hour two, the marginal quality of a submission drops fast. The cost to the candidate, who may be doing this for three companies simultaneously, on evenings and weekends, while holding down a current job — is real. Teams that have moved to 60-minute exercises are not getting worse candidates. They are getting the same candidates, with less resentment at the start of the relationship.

The length of an exercise signals what you value. Long assignments say you value effort over clarity, or that you have not worked out what you are actually testing. Senior engineers with options notice this and drop out accordingly.

Engineering interviews have always been proxy measurements. Whiteboard algorithms proxy for reasoning. Take-homes proxy for working practice. The question worth asking — not just of the take-home, but of every part of your process — is whether the proxy still maps to what you actually care about. For most teams running four-hour take-homes in 2026, the honest answer is no.