How to Design a Take-Home Assignment Candidates Won't Resent

Take-home assignments are the most divisive stage in technical hiring. Done well, they give you better signal than any interview: real code, written the way the candidate actually works, on a problem resembling the job. Done badly, they're an unpaid weekend that quietly removes every candidate with options — which is to say, every candidate you most want.

The difference is almost entirely design.

Decide whether you need one at all

Before designing anything, check that a take-home is the right instrument. It's a good fit when:

• The role involves substantial independent work you can't observe in an interview.
• You want to see real code — structure, naming, tests, commits — rather than whiteboard output.
• Your candidates include people who interview poorly but work excellently, which is a large group.

It's a poor fit when you could pair with them for ninety minutes instead and learn the same things while also seeing how they collaborate. Pairing is faster for you, less costly for them, and often higher signal. Consider it first, and offer it as an alternative even when you do use take-homes — some candidates strongly prefer one or the other.

The rules that keep candidates in your process

Cap it at three hours, and mean it

State the time limit, then design something a competent person genuinely finishes inside it. The common failure is an exercise advertised at "about three hours" that realistically takes eight. Candidates notice, and it damages trust before you've even met.

Test your own assignment: have two engineers on your team complete it cold and time them honestly. Then design for the slower one.

Cap what you evaluate, too

Tell candidates explicitly what you will and won't assess. "We're looking at how you structure the code and handle errors. Don't build authentication, don't style it, don't deploy it." Without this, conscientious candidates gold-plate — spending nine hours because they can't tell what matters — and you've selected for free time rather than ability.

Pay for anything substantial

If the exercise takes more than about two hours, pay for it. A modest fee changes the dynamic entirely: it signals you value their time, it makes an extended exercise defensible, and it markedly improves completion rates among senior candidates.

It also imposes useful discipline on you. Teams paying for take-homes design shorter ones.

Make it resemble the actual job

The best assignments are small versions of real work: extend an existing small codebase, fix a bug in unfamiliar code, build a small endpoint against a real API, or review a pull request and comment on it.

That last one is underused and excellent. It takes forty minutes, is impossible to outsource convincingly, and tells you how someone thinks about other people's code — which is most of what engineers actually do.

Avoid abstract puzzles disconnected from your product. They measure puzzle practice.

Let them use their real tools

Candidates work with AI assistants, documentation, and their usual editor setup. Assignments that pretend otherwise test compliance, not ability.

Design around it instead: the follow-up conversation is where the real evaluation happens. Ask them to walk through a decision, change a requirement live, or explain a trade-off. Someone who genuinely understands their submission handles that easily; someone who doesn't becomes obvious within minutes. This is a better filter than any honour-system rule, and it doesn't insult the people who follow the rules.

Always debrief it live

Never evaluate a submission in isolation. A thirty-minute conversation about their code adds enormous signal: why this structure, what would you change with another day, how would you handle ten times the load, where do you think this is weakest?

It also protects candidates from being rejected over a misread. And it's the stage where the difference between deep understanding and surface assembly becomes unmistakable.

What to evaluate, and how

Write your criteria before you see any submissions, and score every candidate against the same list. Otherwise you'll rationalise a preference you formed in the first thirty seconds.

Reasonable criteria for most roles:

• Does it work? Meets the stated requirements.
• Is it readable? Naming, structure, and whether someone else could maintain it.
• Is it appropriately tested? Judgment about what deserves a test, not raw coverage.
• How does it handle failure? Errors, edge cases, bad input.
• Did they follow the brief — including the instruction not to gold-plate?
• Is the README clear? Assumptions, trade-offs, what they'd do with more time.

That last item is worth weighting heavily. A candidate who documents their assumptions and names their own shortcuts is showing you exactly the judgment you're hiring for.

Mistakes that cost you good candidates

• No time limit stated. Candidates assume more is better and resent every hour.
• Vague requirements that force them to guess at scope.
• Building something you'll use. Even the appearance of free labour poisons the process. Never ask for work that touches your actual product.
• Sending it too early. A take-home before any human conversation asks for hours from someone who doesn't yet know if they want the job. Put it after the intro call.
• Slow feedback. Sitting on a submission for two weeks after asking for three hours of unpaid work is the most common complaint candidates have, and it's fully within your control.
• Rejecting with no feedback. They gave you hours. Give them two specific sentences.
• No alternative offered. Candidates with caring responsibilities or a demanding current job are disproportionately excluded by take-homes. Offering a live pairing option keeps them in the process.

The takeaway

A take-home is a request for someone's evenings. Treat it that way: cap it at three hours, say exactly what you're evaluating, pay for anything longer, base it on real work, let people use their real tools, and always debrief live. Offer pairing as an alternative, and turn results around in days. Done properly it's the most informative stage you run — done carelessly it's a silent filter that removes your strongest candidates.

Find candidates worth assessing — post your role on JobsList.dev.