Take-home test alternatives that still tell you something

The take-home test might be the most resented step in software hiring, and most of the resentment is earned. It asks for the most unpaid work, returns the least, and is the easiest step to fake. It also came from a good instinct, which is why it's still around. I want to keep the instinct and replace the format.

Why candidates hate take-homes

Three complaints come up every time, and all three are fair.

The hours are unpaid. A "four-hour" project becomes an eight-hour project once the candidate adds tests, a README, and the polish they assume you're grading. Multiply that by the five companies they're talking to and a job search becomes a second job. The people who can absorb that cost are the ones with the fewest obligations outside work, which is a strange thing to select for.

There's no feedback. Plenty of candidates who finish a take-home get a form rejection or silence. From their side the deal is: spend a weekend, receive nothing, not even a sentence about what was wrong. After that happens twice, they decline the next one. The person declining is often the one you wanted, because they're the one with other offers.

It's easy to outsource. A friend can do it. An assistant can do most of it in minutes. So the artifact you receive tells you that someone, or something, can build a small CRUD app. It doesn't tell you who. Teams patch this with a follow-up call, which is the right instinct, but at that point the call is doing the work and the take-home was an expensive way to schedule it.

I'd have declined most of the take-homes I've seen. That's the test I now apply to anything I send: would I do this, unpaid, for a company I'm not sure about yet?

What the take-home was trying to measure

Take-homes exist because interviews are a bad place to watch someone build. Forty-five minutes at a whiteboard with a stranger watching measures composure more than engineering. The take-home was an attempt to see real work: how the candidate structures a problem, whether they write tests unprompted, how they handle an ambiguous spec, and what their code looks like when nobody is watching.

Those are good things to want. Keep the list. Judge every alternative below on how much of that list it recovers, and at what cost to the candidate and to you.

The alternatives, with their trade-offs

Paid work samples

Pay the candidate for a scoped task, a few hours at a contractor rate, and treat it as a small contract. This fixes the unpaid-hours complaint outright, and it changes the tone of the whole exchange. It costs money per candidate, so you can only afford it late in the pipeline. It needs a task self-contained enough to hand to an outsider. Some candidates can't accept paid work from you because of their employer's rules or their visa. And it doesn't stop outsourcing, though people are less inclined to hand off work they're being paid for.

Pairing sessions on real code

Sit with the candidate for an hour in your repository, or a lightly sanitized copy, and fix a small real issue together. You see how they read unfamiliar code, what questions they ask, and what they do when something doesn't work. This is the closest thing to a day on the job. It costs an engineer-hour per candidate, which caps how many you can run. It needs a prepared issue and a codebase that won't embarrass you. And it's hard on candidates who freeze when watched, so you'll lose some good people to nerves. Write down what you're looking for before the session, or the score becomes "did I enjoy the hour."

Code-reading and debugging exercises under an hour

Give the candidate a small codebase and a failing case. Ask them to explain what the code does, find the defect, and explain why it fails. Then ask for a short written note on how they'd change it. This recovers most of what the take-home wanted (structure, judgment, communication) in a fraction of the time, because reading and debugging are denser signals than building from scratch. The trade-off is that you don't watch them build. If the role is greenfield work, add a short building task. For most roles, most of the job is reading and changing existing code anyway.

Structured portfolio walkthroughs

Have the candidate bring something they built and walk you through it: the design, the worst decision, the bug that took longest, what they'd do differently now. Use the same questions for everyone and a written rubric, or it turns into a chat. It costs the candidate almost nothing, because the work already exists. The weaknesses: candidates whose best work is proprietary can't show it, the artifact might be a group effort or a tutorial, and it's easy to grade charisma by accident. Pair it with one of the shorter exercises instead of relying on it alone.

AI-inclusive assessments that grade the collaboration

Instead of banning assistants, put one inside the exercise and grade the transcript. Did the candidate brief it clearly? Did they catch the suggestion that was wrong? Did they override it, or did they argue with a correct one? This measures a skill most jobs now need daily and that no other format touches. It also defuses the outsourcing problem, because what's being graded is the candidate's judgment inside the conversation, and that's hard to delegate. The grading is harder than checking an answer key and needs a specific rubric. Candidates who've never worked with an assistant are at a disadvantage, which you may or may not consider fair for the role. This is the format I built Evaluator around: it generates a role-specific assessment from a pasted job description and scores code reading, code writing, debugging, communication, trade-offs, and AI collaboration, with the collaboration transcript graded on whether the candidate catches a wrong suggestion, overrides it, and briefs the assistant well.

Short timed exercises with a rubric

Forty-five to sixty minutes, a fixed window, a handful of small tasks, a rubric written before anyone sits it. This is the take-home with the hours capped and the outsourcing window mostly closed. It loses the "code when nobody is watching" signal. Timed work also penalizes people who are slow and careful, who are often the people you want. Keep the tasks small enough that a careful person finishes with time to spare.

Keeping any of these under 90 minutes

Ninety minutes of candidate time is my ceiling for anything before an onsite. Past it you're back to selecting for free time.

• Decide what each task measures before you write it. If two tasks measure the same thing, cut one.
• Prefer reading and debugging over building. Reading a hundred lines takes minutes. Writing them takes hours, and the reading tells you more per minute.
• Provide the scaffolding. Repository set up, dependencies installed, tests runnable. Nobody learns anything from watching a candidate fight a toolchain.
• Ban the polish. Say in writing that a README, CI config, and formatting won't be graded. Candidates over-deliver unless told not to.
• Pilot it on your own team with a stopwatch. If your senior engineer needs 70 minutes, a nervous candidate will need something like 120. Cut until your engineer finishes in 40.
• Grade what you asked for and nothing else. Extra credit for extras is how a 60-minute exercise becomes a weekend.

What to tell candidates up front

Put all of this in writing before they start:

• How long it should take, and that going over won't improve their score.
• Exactly what's graded and what isn't.
• Whether they can use an AI assistant, and if so, that the collaboration itself is part of what's assessed.
• What happens next and when they'll hear, with a date.
• That they'll get feedback. Then send it, even three sentences. It's the cheapest way to become the process candidates recommend to their friends.

The cost of telling candidates everything is that some will game it. I'd take that trade. A candidate who reads the instructions carefully and does exactly what was asked is showing you a skill you'll want on Monday.

Whichever format you pick, write the rubric first. If you want a ready-made version of the reading, debugging, and AI-collaboration exercises above, you can generate one from a pasted job description at tryevaluator.com/try in about 100 seconds, no signup.