Anyone Can Pass Your Take-Home

The take-home, the screen, the résumé: all of them were proxies for something you could not observe directly. The proxies got cheap at the same moment the thing they stood for got more valuable. Here is what I would test instead.

By Jason Waldrip, with Claude August 14, 2026 09:35

You open the first take-home. Clean commit history, real tests, a README that explains the tradeoffs. Good candidate. You open the second one. Also clean, also tested, also a thoughtful README. You open the third and the fourth and somewhere in there you stop reading carefully, because they’re all good, and “all good” is another way of saying you now know nothing about any of them that you didn’t know before you sent the assignment.

Then you do the honest thing and ask yourself how much of that you could produce in an afternoon without writing a line. The answer is most of it. The answer has been most of it for a while.

Sit in that before reaching for a fix, because the reflex fix is bad. The reflex is to make the assignment harder, or to proctor it, or to ban the tools. All three assume the assignment still measures something and just needs protecting. It doesn’t.

the proxy nobody named

Nobody ever wanted to hire someone for their ability to produce a working CRUD endpoint. That was never the trait. The trait is something like: given an ambiguous situation, a deadline, and four plausible directions, this person picks a good one and knows why.

You can’t observe that in ninety minutes. So the industry built proxies. Ship a small thing under mild time pressure and let me read the result, because the shape of the result leaks the reasoning behind it. Which corners you cut. Whether you wrote the test for the thing that would actually break. Whether you reached for a framework the problem didn’t earn.

That proxy worked for one reason, and it wasn’t that anyone thought it was a great simulation of the job. It worked because production was expensive. Four hours of your Saturday bought me a signal that was hard to fake, not because you were being watched, but because faking it cost about as much as doing it. The cost was the honesty. Remove the cost and you’ve removed the mechanism, not just the difficulty.

both ends automated at once

The résumé went first and nobody mourned it. Candidates generate applications by the hundred now, tailored per posting, and the whole genre collapsed into noise. So companies answered with automated screening, which candidates answered with keyword-shaped generated résumés, which companies answered with more filtering.

Two systems are now talking to each other at volume, and no human on either end learns anything. The candidate doesn’t learn whether the job is right. The company doesn’t learn whether the person is. Every round trip burns real time from a person who has a finite amount of it, which is the part I actually mind. If you believe time is worth more than capital (I do, it’s on my about page and it isn’t decoration) then a hiring process that wastes forty hours of a good engineer’s month to produce a coin flip isn’t neutral. It’s a cost you’re imposing on people, and you should be able to say what you bought with it.

Right now most loops can’t say. They’re running a test that everyone passes and treating the pass as information.

the ten minutes I actually got paid for

Brandfolder, 2015. Ruby was crashing generating large zip files. Heavy IO, wrong tool for the shape of the workload. We carved that piece out into Go and shipped multi-gigabyte archives at minimal cost.

Imagine that as a take-home. “Here’s a service that times out generating large archives. Fix it.” A strong candidate in 2015 profiles it, finds the allocations, streams the response instead of buffering it, adds a test, writes a clear PR description. Genuinely good work. A fleet of agents does all of that today before lunch, and does it well.

Neither one, unprompted, stops and says the language is wrong for this workload. That call took about ten minutes. It was worth more than everything I typed that year, and no take-home I’ve ever seen would have surfaced it, because the assignment already contains the assumption that the code in front of you is the code that should exist.

Which points at the actual test. Don’t ask someone to build the thing. Ask them what they would delete.

test the half nobody submits

Every technology choice on this site is written in two halves: when I reach for it, and when I don’t. The second half is where the credibility lives, and it’s the half that generated work almost never produces, because a model asked to justify a stack will justify the stack. Ask it when the stack is wrong and you get a general answer. Ask a person who has operated one at 2am and you get a specific one, usually with a scar attached.

So build the loop around the second half.

1. Give them a real decision, already made, and slightly wrong. A repo where something load-bearing was chosen badly, and several things were chosen fine. Ask what they would change, what they would leave, and what they would need to know before touching either. Watch what they leave alone. Restraint is the trait, and it’s invisible on a build-it assignment because building rewards touching everything.
2. Ask when they wouldn’t use the thing they’re best at. The Kubernetes person who can’t describe the team size below which it’s a tax hasn’t operated it, they’ve installed it. At CommercialTribe I moved us onto GCP and Kubernetes because it was the cheapest path to stability at our load. That sentence carries a load. Someone who says the same words with no load behind them is telling you about a conference talk.
3. Hand them the fleet and watch how they drive. Banning the tools tests for a job that no longer exists. Let them use whatever they’d use on a Tuesday, then read the transcript instead of the diff. Where did they accept output, where did they push back, what did they check before believing it? That transcript is the closest thing to a direct recording of judgment I’ve found, and it didn’t exist three years ago.
4. Pay for anything long. If the exercise is big enough to be worth reading, it’s big enough to be worth paying for. Real ownership, not the story of it, starts before the offer letter.

None of that scales the way a take-home scales, and I’m not going to pretend otherwise. It takes a senior person’s real attention per candidate, which is expensive, and the whole appeal of the take-home was that it converted attention into homework. That trade is over. The homework is free now, and free homework tells you nothing, so the attention comes back onto your side of the table whether you budgeted for it or not.

what you’re hiring against

Here’s the part that makes this urgent rather than merely annoying.

When production was expensive, a mediocre hire was slow. They shipped less, you noticed, you corrected. The cost of a bad judgment call was bounded by how fast one person could type it into existence.

That bound is gone. Point someone with weak judgment at a fleet and they will produce an enormous amount of confident, well-tested, beautifully documented work in the wrong direction, and it will look exactly like the work of someone with strong judgment right up until you’re a quarter deep in a design that can’t hold. The blast radius of a hiring mistake scaled with everything else. Multiply judgment by a fleet and you get something new. Multiply the absence of it by the same fleet and you get a much larger version of the same nothing, faster.

So the loop that mattered least when hands were the constraint matters most now that they aren’t. That’s an uncomfortable place to land, because the answer isn’t a better assignment. It’s more of the thing you were trying to avoid spending: a senior person, in the room, asking questions that can’t be answered from a general model of the world.

What’s the last decision you made that a very good, very fast machine would have gotten wrong? If you can answer that about yourself in specifics, you know what to ask a candidate. If you can’t, that’s the more interesting problem, and it isn’t a hiring problem.