Why the take-home didn't die, it grew a second stage
The unsupervised take-home submission's signal degraded fastest of any interview format once AI coding assistants became ubiquitous — a submission that looks polished no longer reliably indicates the person who submitted it understands what's in it. Rather than dropping take-homes entirely, a large share of companies responded by attaching a mandatory live defense to them: you still build something asynchronously (often still with AI tools allowed, sometimes even expected), but you're then interviewed about it — asked to explain specific decisions, walk through specific sections of your own code, and often extend it live with a new requirement, on the spot, days or weeks after you wrote the original version. The take-home stopped being the whole signal and became the setup for the round that actually generates most of the signal.
The core risk: explaining code you don't remember writing
The single biggest practical failure mode is memory, not competence — you built this two weeks ago, possibly leaned on an AI assistant for parts of it, and now need to explain a specific design decision live without having reviewed it since. The fix is almost entirely preparation, not improvisation: re-read your own submission shortly before the defense, specifically looking for the decisions you'd struggle to justify from memory alone — an unusual data structure choice, a shortcut you took under time pressure, a section where you leaned heavily on an AI suggestion without fully internalizing why it worked. If you can identify your own weak spots before the interviewer does, you can walk in with an honest, prepared answer instead of visibly reconstructing your reasoning live.
"Why did you do it this way" is rarely adversarial
When an interviewer asks about a specific choice, the default assumption should be genuine curiosity about your reasoning, not an accusation that the choice was wrong. A confident, honest answer — including "I optimized for finishing within the time limit here; given more time I'd reconsider X" — reads far better than a defensive justification of a decision you don't actually still believe was optimal. Interviewers are frequently more interested in whether you can accurately narrate your own past reasoning (a real signal about self-awareness and communication) than in whether the original decision was the best possible one.
Being asked to extend it live
A common defense-round addition: "now add feature X" or "how would you change this to handle Y," applied live to your own take-home code. This is functionally the Extending an Existing Codebase topic's skillset, aimed at code you happen to be the original author of — the advantage is you already know the conventions (you set them), the disadvantage is you're expected to move faster because of that familiarity, and hesitating too long reads as not actually understanding your own submission as well as the interviewer expected.
If you used AI tools while building it, say so plainly
Given how common AI-assisted take-home submissions now are, most companies running this format assume some AI involvement and aren't looking for a confession — they're looking for evidence you understood and verified what was produced. If asked directly, answer honestly and specifically ("I used it to scaffold the initial CRUD layer, then wrote the validation logic and tests myself") rather than either overclaiming full manual authorship or being vague about what was and wasn't yours — the follow-up questions in the defense round exist specifically to probe whether "I understood and can defend this" is true regardless of who typed the first draft.