A take-home assignment that filtered candidates cleanly in 2022 now sorts almost nobody. Interview Coder and Leetcode Wizard chew through a standard “build a small REST endpoint” or “parse this log format” prompt in a few minutes, comments included, and hand back an explanation that reads like a competent mid-level engineer wrote it. Karat’s 2026 survey put the shift bluntly: 71% of engineering leaders say AI has made technical skills harder to assess, and the format that lost the most signal was the take-home.
So hiring teams are moving weight back to live rounds, where they can watch you think. If you’re prepping right now, the useful question is narrower than which format is fairer. You want to know what each one actually measures in 2026, and how not to get caught flat in either.
What the take-home used to buy you
The take-home earned its popularity for good reasons. It respects people who interview badly under a whiteboard and a stopwatch. It looks more like the job: an open editor, real docs, a few hours to design something instead of racing a timer. Teams could compare submissions on the same prompt and read actual code instead of guessing from a phone-screen conversation. For a while, a clean take-home was one of the better predictors a hiring manager had.
It worked because the artifact was hard to fake. Writing a small, correct, well-structured service in three hours took real skill, and the quality of the result tracked closely with the quality of the engineer. That link is what broke.
The signal AI erased
Between July 2025 and January 2026, one assessment vendor flagged signs of AI use in 38.5% of roughly 19,000 technical interviews. In purely technical roles the rate climbed to 48%, and 61% of the candidates who used AI still cleared the passing bar. Most of the people leaning on a co-pilot passed anyway. When the artifact no longer separates the strong candidate from the strong prompter, the take-home stops doing its one job.
The uncomfortable part is that you can’t tell from the submission. A model writes idiomatic code, adds tests, and will generate a humanized explanation of its own output on request. Plagiarism checkers look for copied text, not for work generated fresh for this exact prompt. So a hiring team reading a polished repo has no reliable way to answer the only question that counts, which is whether this person can do the work when the model is having a bad day.
Why interviewers went back to watching you work
Live coding came back for a blunt reason. Presence is expensive to fake. In a live round the interviewer sees the order you attack a problem, the wrong turn you back out of, the way you read an error message. Some companies now hand you an AI assistant on purpose and grade how you use it: do you check what it wrote, do you catch the subtle bug it slipped in. Others switch it off and want to see you reason cold. Both reveal something a repo can’t.
The tradeoff is real. Live rounds punish nerves and eat interviewer time, and they can measure comfort-under-observation as much as raw skill. Nobody claims they’re perfect. They just survive contact with AI better than an async task does.
| Interview format | What it measures well | How AI affects the signal | Typical candidate time |
|---|---|---|---|
| Classic async take-home | Code structure, design sense, and working software on a real prompt | Signal largely erased; standard prompts are solved by AI tools in minutes and can’t be traced to the candidate | 2 to 4 hours, unsupervised |
| Structured take-home plus walkthrough | Whether the candidate can build and then defend each decision under questioning | Holds up; the code can be AI-assisted but the live explanation can’t be faked | 1 to 4 hour task, then a 30 to 45 minute discussion |
| Live coding, AI turned off | Cold problem-solving, debugging, and data-structure choices under observation | Unaffected during the session; tests the skills AI would otherwise mask | 45 to 60 minutes, supervised |
| Live coding, AI allowed | How the candidate prompts, verifies, and corrects an AI assistant in real time | Central to the test rather than a threat to it | 45 to 60 minutes, supervised |
The hybrid that’s actually holding up
The format gaining ground in 2026 keeps the take-home but bolts a conversation onto it. You get a scoped task, usually one to four hours against a real product goal, then a 30 to 45 minute session where you walk an engineer through what you built and why. The question quietly changes from “did you write this” to “can you defend every decision in it.” A model can hand you the code. It can’t sit in the room and explain why you picked a queue over a cron job when the interviewer pushes back.
The retention numbers back the format. Teams using structured take-homes with a walkthrough reported 41% fewer early departures than teams relying on live interviews alone, which tracks: the walkthrough surfaces the people who can build and also reason about what they built, a rarer combination than either skill alone.
Prepping for a take-home in 2026
Assume the walkthrough is coming even if the instructions don’t mention it. Use AI if it’s allowed, but treat anything it generates as code you’re about to defend line by line to a skeptical senior engineer, because that may be exactly the situation you’re in. Read every function it wrote. If you can’t explain why a piece is there, cut it or replace it with something you understand.
Keep the scope tight and make it run. A smaller feature that works end to end beats an ambitious half-finished one every time. Write a short note with your submission covering the tradeoffs you made: the corner you cut on purpose and what you’d build with another day. That note does double duty. It shows judgment, and it becomes your script for the walkthrough.
Some prompts you’ll see phrased like these:
- “Build a small service that ingests these webhook events and exposes a summary endpoint. Two to three hours, use whatever stack you like.”
- “Here’s a repo with a failing feature. Fix it, add tests, and be ready to explain your changes.”
- “Design and implement a rate limiter for this API, then walk us through your approach.”
Prepping for live coding
The skill that carries a live round is narrating without freezing. Practice saying what you’re about to try before you type it, so the interviewer can follow your reasoning and nudge you before you burn ten minutes on a dead end. Silence reads as being stuck even when you’re thinking clearly.
Find out the AI policy before the session and practice for it. If the tool is allowed, rehearse the loop of prompting, reading critically, and rejecting the weak suggestion, because fumbling your own assistant in front of an interviewer looks worse than not having one. If it’s off, drill the fundamentals cold: parsing input, a clean data-structure choice, debugging without a model whispering the fix.
Know the house style of where you’re interviewing. Stripe, Vercel, Linear, and PostHog run pair programming or live work in a real IDE rather than abstract algorithm puzzles, and the closer your prep looks to shipping a small real feature, the better you’ll do. Build a couple of tiny apps against an unfamiliar API under a timer. That rehearses the exact muscle a live round tests: getting something working in a codebase you don’t fully know, out loud, while someone watches.
The formats will keep shifting as the tools do. What won’t change is that companies are done trusting an artifact they can’t trace to a person, and the rounds that make you think in front of them are the ones worth over-preparing for.
Practice the behavioral round:
