How to evaluate a take-home assignment

The four things to grade

1. Correctness — does it do what the brief asked?
2. Readability — could you review this without rewriting it?
3. Judgement — what did they do with the ambiguity you left in?
4. Defence — can they explain the decisions in conversation?

Publish the criteria with the task

Candidates guess at what you value, and they guess wrong in expensive ways — spending four hours on a front end when you cared about test coverage. Including the grading criteria in the brief costs you nothing, removes the guessing, and makes the submissions comparable. It also exposes criteria you cannot actually articulate, which is worth finding out before you start grading rather than afterwards.

Leave deliberate ambiguity, and grade what they do with it

The most informative part of a take-home is usually a requirement you left under-specified on purpose. Strong candidates notice it and either ask or state an assumption in the README. Weaker ones silently pick one interpretation and build. This is the closest a take-home gets to testing judgement rather than execution, and it is the part most grading rubrics forget to include.

What to ignore

• Anything you did not ask for. Extra features are not evidence of quality; they are evidence of unclear scope.
• Styling and polish, unless the role is front-end and you said so.
• Technology choice, unless you constrained it. Grading someone down for not using your stack tests familiarity, not ability.
• Time taken, beyond the limit you set. Rewarding people who spent eight hours on a two-hour task selects for free time.

Keep the time limit honest

Build the task yourself first and halve the scope, because a candidate with a job, no context on your conventions and no access to your codebase will take roughly double what you take. State the limit, mean it, and say explicitly that you would rather see an incomplete submission with a note about what was left than a complete one that took six hours. Then grade accordingly, or the statement is worse than useless.

Always follow up in conversation

A thirty-minute walkthrough after the submission roughly doubles the information you get. Ask them to explain one decision, then extend the work live — add a small requirement and watch them modify their own code. This also settles the authorship question without an accusation: someone who built it can extend it, and someone who did not, cannot. Given how easily code can be generated now, the live extension is the only part of the assessment that reliably holds.

Score consistently

• Grade all submissions against the written rubric, not against each other. Comparative grading drifts with whoever you read first.
• Grade blind where you can, with names removed from the repository.
• Two graders for borderline cases, scoring independently before comparing.
• Cap the time you spend. Thirty minutes per submission. Longer means you are reading for impression rather than against criteria.

Write the brief so it can be graded

• State the time limit and mean it. “Spend no more than two hours; we would rather see it unfinished with a note.”
• Say what you are grading, in the order you care about. Candidates optimise for whatever you name first.
• Provide the scaffolding. A repository that already runs, with dependencies installed and a test command that works, removes an hour of setup that tests nothing.
• Name the ambiguity you will not resolve. “Some requirements are deliberately open — state your assumptions in the README” makes judgement gradeable instead of accidental.
• Give a realistic deadline. A week, not forty-eight hours. Short deadlines filter on current workload rather than ability.

Common grading mistakes

The two that do most damage are grading comparatively and grading on impression. Comparative grading means the first submission you read sets the bar for everyone after it, which makes your standard a function of reading order. Impression grading shows up as a long, admiring paragraph about a submission and a one-line dismissal of another, with no rubric scores on either. Both are fixed by the same discipline: score each criterion separately, in writing, before forming an overall view.

Be honest about the cost to candidates

A take-home is unpaid work, and it filters on available time rather than ability. That is a real cost, and it falls hardest on candidates with caring responsibilities or a demanding current job. Keep it short, pay for anything substantial, and offer a live alternative for candidates who would rather do a longer interview instead. See how to test coding skills without LeetCode.

Where Interviewer Mode fits

Disclosure: we make CoPilot Interview, which includes Interviewer Mode for the hiring side and a real-time assistant used by candidates. We have an interest in you using the first, and our view of the second is that interviews should be designed to measure something an assistant cannot fake. Weigh the advice below accordingly.

Frequently asked questions

How do you evaluate a take-home assignment?

Grade correctness, readability, how they handled ambiguity you deliberately left in the brief, and whether they can defend the decisions in a short follow-up conversation. Ignore anything you did not ask for, including extra features and styling.

How long should a take-home assignment take?

Two hours at most. Build it yourself first and halve the scope — a candidate with a job and no context on your conventions will take roughly double your time. Pay for anything longer.

How do I know the candidate wrote it themselves?

Follow up live: ask them to walk through one decision and then extend the work with a small new requirement. Someone who built it can modify it comfortably. This settles the question without an accusation and is better assessment regardless.

Should take-home assignments be paid?

Anything beyond about two hours should be. Unpaid work of real length filters on who has spare time rather than on ability, which disadvantages candidates with caring responsibilities or demanding current jobs.

Is it fair to reject someone for an incomplete take-home?

Only if you did not say the time limit was real. If you asked for two hours, an incomplete submission with a note explaining what was left and why is a correct response, and should score well on judgement.