For years my answer to the take-home coding challenge was a polite no. Not because they measure nothing — a real, buildable problem tells you far more than a whiteboard riddle ever will — but because the price was wrong. The company spends ten minutes emailing a PDF; the candidate spends a weekend building production-shaped software, unpaid, on spec, usually while holding down the job they already have. That asymmetry always felt like the tell. A process that respects your time doesn't open by taking a Saturday of it.
So I'd push back, or decline, and steer toward a conversation instead. A good engineer will out themselves in twenty minutes of talking about a system they actually built. Why spend two days re-proving it on a toy?
Then AI changed the arithmetic, and I had to change my mind.
The cost that made them unfair just collapsed
The reason a take-home was expensive was never the thinking. It was the typing — the scaffolding, the boilerplate, the test harness, the Dockerfile, the README, the hundred small mechanical decisions between a good design in your head and a repository someone else can run. That's the part that ate the weekend. And that's exactly the part a competent AI pair now does in an afternoon.
When the mechanical cost of producing the code drops toward zero, the old objection — "this asks too much of my time" — mostly evaporates. What's left is the part that was always the point: the design, the trade-offs, the judgement. The take-home stops being a test of endurance and becomes a test of taste. That's a much better thing to be measuring, and it's why I now think the format deserves a second look.
A challenge that got the new rules right
The one that turned me around was, on paper, almost aggressively boring: model a vending machine. Insert coins, buy a product, return coins, give change, let a technician refill it. The kind of problem you could hack into a single file in an hour.
That was the trap, and the brief said so out loud. It wasn't testing whether the thing works — it was testing how you build something that has to be maintained by other people for years. Architecture, boundaries, testing strategy, how the design absorbs a change you haven't been told about yet. And crucially, the brief was explicit about AI: use it, we expect you to. But — you will defend this solution in a technical interview. We'll ask why you chose this boundary, what you rejected, how you'd extend it. The line that stuck with me was that the code should be something you could confidently explain, modify and extend if AI agents disappeared tomorrow.
That single sentence is the whole shift. It hands you the fast tools and then quietly moves the finish line past them.
AI moves the signal, it doesn't erase it
The worry with "AI-assisted take-homes" is obvious: if a model can produce the solution, what does submitting it prove? Nothing — if submitting it were the end. It isn't. The defense is.
You can generate a hexagonal, domain-driven vending machine in minutes. You cannot fake, in a live conversation, why the machine is an aggregate and a coin is a value object; why money is integer cents and never a float; why the change-making search is exhaustive instead of greedy (a greedy "biggest coin first" pass will wrongly refuse change it could actually make); why business rules live in the domain and never in the CLI, so the exact same core works whether an interviewer swaps the front-end for an HTTP API. Either you understand the thing you shipped or you fold on the first "and why did you do it that way?"
That's what AI actually did to the take-home: it didn't remove the signal, it moved it. From can you produce this? — which used to cost a weekend and is now nearly free, and therefore proves nearly nothing — to do you understand this?, which is still expensive, still uncoachable, and exactly what you were trying to hire for the whole time.
What I did differently
So I leaned into the part that now carries the weight. The code came together quickly. Then I spent the real effort making sure I owned every decision in it — I wrote myself a plain-language guide to the whole thing, one section per design choice, so for any question an interviewer could throw I had a file to point at and a reason to give. Not to memorise answers, but because if you can't write the why down in plain words, you don't actually understand it yet, and the interview will find that seam.
The solution is public if you want to see what "senior take-home" looks like when the goal is defensibility rather than cleverness: github.com/malofu/vmachine.
The honest verdict
I'm not fully converted. A bad take-home is still a bad take-home — vague, ten hours long, graded by whether you guessed the reviewer's favourite pattern. AI doesn't fix any of that.
But the specific thing I objected to — the time cost, the disrespect baked into the ask — is the thing AI genuinely dissolves. And in return we get to keep the thing take-homes were always best at: a real artifact, built the way you actually build, that you then have to stand behind and explain. Fast to produce, impossible to fake in the defense.
That's a good trade. Technical interviews are back — and for once, they're worth the time.