The common complaint about take-home assignments is that companies are extracting free labour. Occasionally true, but not the main problem. The main problem is that most briefs specify a task without specifying a budget, and without a time limit candidates compete on effort. One person spends three hours, another fourteen, and the one who spent fourteen usually wins — which teaches everyone to spend fourteen.

That is an arms race with no upper bound. You opt out by fixing the scope yourself, in writing, before you start.

What reasonable looks like

A defensible take-home has four properties: a stated time budget, a scope that fits it, a task resembling the job, and a clear place in the process. Miss one and it measures something other than ability.

Practitioners running these processes land in a similar range:

  • Two to four hours for most individual-contributor roles. Treat this as the default.
  • Up to about six hours for senior roles where a shorter task cannot demonstrate the skill, and only late in the process.
  • Anything described as "a weekend" is a design failure. It excludes anyone with caring responsibilities or a demanding current job, and selects for availability rather than ability.

A well-designed task is also abstracted from the company's live problems: synthetic data, a fictional scenario, a public dataset.

Negotiating scope without sounding difficult

The most useful message you can send is short, positive and specific:

Happy to do this. So I can pitch the depth correctly — should I budget around three hours? And if I have to choose, would you rather see the analysis or the implementation?

Three things happen there. You have accepted the task, so you are not the difficult candidate. You have put a number on the table, so the budget is mutual. And you have asked them to prioritise, which surfaces what they care about.

The reply tells you a great deal. "Three hours is right, focus on the analysis" is a well-run process. "Take as long as you need" means you set the limit, state it and stop. Evasiveness, or a nudge toward more, tells you how the organisation treats people's time.

If the brief is oversized, propose a reduction rather than refusing: complete one of three sections fully, or deliver an outline plus one worked example, and explain the trade-off in a sentence. Reasonable employers accept this.

When it is a red flag

Unpaid is normal for a bounded exercise. The real concerns are about scope, not payment.

  • The task is a real, current, named company problem, with real data or customer accounts.
  • The output is directly usable — copy they could publish, code that ships.
  • The brief arrives before any conversation with a human. A serious process spends its own time before it spends yours.
  • They ask for multiple rounds of unpaid work, or revisions to a submission.
  • The scope keeps growing after you have agreed it.

Two or more together is a reasonable basis for declining, or for asking to be paid. Asking is more normal than people think, particularly for senior and contract roles: "This is beyond a standard exercise, so I would treat it as a short paid engagement at my day rate" is a professional sentence, and the response is diagnostic.

A special case is the "strategy day" or "90-day plan", common for senior commercial and operations roles. Presenting your thinking about their market is legitimate; handing over an operational plan for a business you have not seen inside is free consulting. Give frameworks and the questions you would ask, not finished answers, and say that the specifics depend on internal data you do not have. That is the better answer anyway — a confident plan built on public information is a warning sign.

Set the budget yourself

Decide your time limit before you open the brief, tell them what it is, and stop when you reach it. Submit what you have with a short note on what more time would have bought. A disciplined three-hour submission with stated trade-offs reads better than an unbounded one that shows you cannot scope work.

How to submit it so it actually gets read

Assume the reviewer gives it fifteen minutes, possibly the evening before the panel. Most submissions fail here rather than on substance.

  1. Lead with the answer. The first paragraph states your conclusion, not the methodology.
  2. Write a one-page summary whatever the format. Code, spreadsheet, deck or model all get a covering document: the answer, the approach in three lines, the assumptions, and what you would do next with more time.
  3. State your assumptions. Every brief is underspecified. Naming the gaps and how you closed them is the highest-signal thing in most submissions.
  4. Note the trade-offs. "I spent the time on X because the brief implied it mattered more than Y" demonstrates judgement, which is what is assessed.
  5. Use the format and limits requested. If they asked for five slides, send five, named clearly and opening without an account or a niche tool. Ignoring a constraint reads as carelessness.
The exercise is not testing whether you can do unlimited work. It is testing what you do when the brief is vague and the clock is real, which is the job.

Conventions vary. Take-homes are common in technology, data and design roles almost everywhere, less usual in continental European processes that lean on structured interviews and assessment centres, and in parts of the Nordics and the Netherlands unpaid work is viewed sceptically. Ask what the process involves before the first call, and afterwards ask how the assignment was evaluated.