Why we pay for the take home exercise

We do not set a take-home exercise for every candidate. When we do, three things are true.

It is scoped to under four hours.
It is paid at the candidate’s own day rate.
Whatever they produce belongs to them.

People tend to notice the second point first. Paying for a hiring exercise still surprises some people, so we should explain the reasoning plainly. That includes the parts that benefit us.

If the work helps us make a decision, we should pay for it

We are asking somebody to do work that benefits us. It benefits us whether or not we hire them, because it gives us information we would otherwise have to guess at.

Work that benefits the person asking for it is work, and work gets paid for. That is the simple version of the argument.

The usual counterargument is that the candidate benefits too. A take-home exercise can give them a fairer assessment than a short interview or a whiteboard problem. That is true, and it does not change the analysis. The same could be said of any job where both parties benefit from the arrangement.

Unpaid exercises select for spare time before they select for skill

This is the part that matters most, and it is usually left out of the discussion.

Four unpaid hours is a mild inconvenience to somebody with no dependants and a job that ends at six. It is close to impossible for somebody with young children, or caring responsibilities, or a second job, or a current employer who expects long hours.

That means an unpaid exercise does not filter for skill. It filters for available time. Available time is distributed along lines that have nothing to do with engineering ability and quite a lot to do with circumstances.

If you run unpaid exercises and wonder why your pipeline lacks diversity of background, this is one of the mechanisms.

Paying does not fully solve the problem, because the time still has to exist. It does remove the specific unfairness of asking somebody to donate labour they cannot afford to donate.

Paying makes the assessment more reliable

An unpaid exercise produces two failure modes at opposite ends.

Some candidates do the minimum. They may have three other processes running, and they have no reason to prioritise yours. You learn less than you hoped. You then conclude they are mediocre, which may be entirely wrong.

Other candidates massively over-invest. They spend fourteen hours on a four hour exercise because they want the job. Now you are assessing something that does not resemble how they work under normal conditions.

You also cannot tell which candidates did that. You end up comparing four-hour work against fourteen-hour work with no way to normalise it, or compare it fairly.

Paying changes the framing. The exercise becomes a small piece of contract work with a defined scope. The expectation that it takes about four hours is credible because it is being paid for as four hours.

The submissions we get back are much more consistent. They also look far more like how people actually work.

The candidate keeps the work

We do not take ownership of the output. It is theirs, and they are free to use it, publish it, or put it in their portfolio.

This closes off an ugly possibility that the industry has a genuine history of. If a company sets an exercise that happens to solve a real problem, gets fifty submissions, and retains rights to all of them, it has obtained a substantial amount of engineering for the price of some job adverts.

We have seen exercises that were transparently a real backlog item. From the outside, there is no way to tell whether that is what you are being handed.

Leaving the work with the candidate removes the incentive entirely. It also means we can say honestly that the exercise exists for assessment, with no extraction of unpaid work hidden inside it.

The exercise looks like the job

The exercise is deliberately a realistic slice of client work. It avoids algorithm puzzles, tricks, and greenfield projects with no constraints.

Usually it is a small existing codebase with a change to make, because that is what the job is. Reading somebody else’s code, understanding a system you did not design, and making a careful change is the daily reality of the work far more than writing something new on a blank page.

We include something ambiguous on purpose. What a candidate does with that ambiguity is one of the most useful signals available. By signal, we mean evidence that helps us understand how they will work.

Some people ask. Some make a reasonable decision and document it. Both are good answers.

Silently guessing and not mentioning it is the one that gives us pause. On a client project, that is how a misunderstanding survives to production.

Four hours means four hours

The scope is set so that a competent person finishes comfortably within four hours.

We also say explicitly that we would rather see an unfinished submission with a note about what was left than a complete one that took twelve.

If somebody consistently reports that it took much longer, that is our estimate being wrong. It goes back into how we scope the exercise.

That is a small echo of how we price client work. When an estimate is wrong, it is our problem rather than theirs.

We skip the exercise when we already have the evidence

Roughly half of our hires have not done an exercise, because by that point in the process we had enough.

Somebody with substantial public work we could read, or who could talk in convincing depth about systems they had built, has already demonstrated what the exercise would tell us.

Running an exercise as a fixed stage regardless of what you already know is a process serving itself.

If the technical conversation answered the question, adding four hours of anybody’s time to confirm it is a cost with no information attached.

Two engineers review the work before they talk

Two engineers read every submission independently. Each writes their assessment down before speaking to the other reviewer.

That ordering is deliberate. When people discuss first and record afterwards, the more senior or more confident opinion anchors the other. You have then collected one judgement wearing two names.

We assess against criteria written before the exercise was sent, rather than against a general impression.

The criteria are written down before review starts.

Did they understand the existing code.
Is the change in the right place.
What did they do with the ambiguity.
Does it handle the obvious failure cases.
Is it readable by somebody who was not there.

The reviewers score against those criteria.

Disagreement between the two reviewers is interesting rather than a problem. It usually points at a criterion we stated badly.

Twice it has led to us rewriting the exercise, because two competent readers interpreting the brief differently means the brief was the defect.

Every candidate gets a written response

Everybody who does an exercise gets a written response describing what we thought, including the parts that did not land.

They do not get a score or a template. They get Two or three paragraphs from somebody who read it.

This is more effort than sending a rejection, and it follows directly from having paid for the work. If somebody has spent four hours on a piece of work for us, telling them only that we are moving forward with other candidates is a poor return on that.

Several people have replied to say the feedback was more useful than anything they received from processes that went further.

It also keeps us honest. Writing down why somebody was declined forces the reasoning to be specific. A reason that cannot be written down plainly usually reflects a preference.

A take-home exercise only measures part of the job

An exercise is good at showing how somebody makes a careful change to an existing system. It is poor at almost everything else, so we are clear about that instead of treating it as a general assessment.

It will not tell you several things that matter on a small team.

How somebody behaves in a disagreement.
How they handle being wrong.
Whether they can explain a technical trade-off to a client who does not want to hear it.
What they are like when a system is down and everybody is tired.

Those things matter at least as much on a small team. They surface in conversation rather than in code.

So the exercise is one input among several, weighted accordingly. We have hired people whose exercise was merely adequate and whose discussion of it was excellent, on the grounds that the second is closer to the job.

We have declined people whose submission was flawless and who could not account for a single decision in it.

The common objections are weaker than they look

It is expensive

It is, mildly. A handful of paid exercises per role is a real number. It is small against the cost of a bad hire or of losing a good candidate to a competitor with a less extractive process.

It complicates payment

Yes, particularly across borders. It is an administrative task rather than an obstacle, and it has never once been the reason we could not proceed.

Serious candidates will do it unpaid

Some will. The ones who will not are disproportionately the ones with the least spare time, which is not a selection criterion anybody would defend if they stated it out loud.

We pay the candidate’s own rate

We ask the candidate what their day rate is, or what it would be, and we pay four hours of it.

We use their rate instead of a flat fee or a token amount dressed up as a gesture.

A flat fee sounds fairer and is not, because the same number is meaningful to somebody early in their career and faintly insulting to somebody senior.

Asking for their rate has the additional benefit of being an honest early signal about expectations. That is a conversation both parties are usually relieved to have had before the offer stage rather than after it.

Nobody has ever quoted a number we thought was unreasonable. That slightly surprised us the first year and stopped surprising us afterwards.