Take-home assignments were supposed to fix technical interviewing. Instead of judging someone on how well they think aloud under fluorescent lights, you get to watch them do something close to the actual job. The logic still holds. The execution usually does not.
In practice, most take-homes have quietly become a filter on free time rather than a filter on skill. Candidates with caregiving responsibilities, a demanding current job, or a second source of income drop out first. The people who finish are not always the strongest applicants. Sometimes they are just the ones with the emptiest calendar.
Here is how to tell whether your assignment is shrinking your pipeline, and what to change before your next req opens.
The time cost is higher than your team thinks
Ask a hiring team how long their take-home takes and you will hear something like three hours. Ask the candidates who completed it and you will hear seven or eight.
The gap comes from setup and ambiguity. Your engineers already have the repo cloned, the environment configured, and the domain context sitting in their heads. A candidate starts from nothing, reads the instructions twice, and then burns an hour deciding how much polish you actually expect.
Time it honestly before you send it. Hand the assignment to someone outside the team who has never seen your codebase and ask them to do it cold, then report the real number. If it comes in above four hours, you are asking for a weekend, not an evening.
Vague prompts produce noise instead of signal
"Build a small app that lets users track expenses" is not a prompt. It is an inkblot test.
One candidate submits a single well-structured file with no tests. Another delivers authentication, a database layer, and a deployment pipeline. You cannot compare them fairly because they answered two different questions, and the reviewer ends up rewarding whoever guessed your preferences correctly.
Write down what you are evaluating and what you are deliberately ignoring. If styling does not matter, say so. If you want tests, say how many and what kind. If you would rather see a short README explaining trade-offs than another endpoint, put that in bold at the top. Candidates are not trying to miss the mark; they usually have no way to know where it is.
Unpaid work that could ship is a reputation problem
There is a real difference between a scoped exercise and a slice of your roadmap. If a submission could plausibly be merged into production with light cleanup, you have crossed a line, and candidates can tell.
Word travels fast. One widely shared post about a company that outsourced a feature to applicants will reach more engineers than your careers page will all year.
Keep the problem synthetic or generic enough that it has no commercial value to you. If you genuinely need to see someone work against your real data, pay for that time and say so in the invitation.
Write the rubric before the assignment goes out
Most take-homes are graded on vibes. A reviewer opens the repo, forms an impression in ninety seconds, and then goes looking for evidence that confirms it. That is not evaluation. That is a first impression with extra steps.
Decide in advance what you are scoring, and cap it at four or five dimensions. Correctness, code structure, testing approach, and communication cover most roles. Define what a weak, adequate, and strong answer looks like for each one, using specific language rather than adjectives.
Then have two people score independently before they talk. If their scores diverge sharply, the problem is usually your rubric, not the candidate.
Ask for a walkthrough instead of more code
The single highest value change most teams can make is shrinking the build and adding a conversation.
Cut the assignment to ninety minutes of work, then spend thirty minutes with the candidate walking through what they built. Ask what they would do with another day. Ask which trade-off they were least comfortable with. Ask them to extend one piece live.
That conversation surfaces things a repo never will: how they reason, how they handle being questioned, and whether they actually understand the code they submitted. It also makes assignments generated with AI tools far less useful as a shortcut, because the candidate has to defend every decision in real time.
Close the loop, even when the answer is no
Candidates who invest six hours and receive a templated rejection remember it. Some of them are people you will want to recruit in two years, and some of them are people your future applicants will ask about you.
You do not need a long letter. Two or three specific sentences about what stood out and where the submission fell short is enough, and it takes a reviewer five minutes if the rubric already exists.
A quick audit you can run this week
Pull the last twenty candidates you sent an assignment to and count how many actually submitted. Anything below seventy percent means the assignment itself is doing damage.
Then check three things. Does the instruction document state the expected time investment? Does it list what you are evaluating? Does every rejected candidate get more than a form email?
Take-homes are still one of the better tools available for predicting job performance. They just have to be scoped like something you are asking a busy professional to do as a favor, because that is exactly what they are.