# The Take-Home Request, Scored to Invest, Counter, or Decline

*You can score a take-home request across hours, stage, fidelity, IP terms, and leverage, then pick one of four responses with a reason you can say to the recruiter.*

- Canonical URL: https://www.refolk.ai/candidates/guides/take-home-request-scored
- Pillar: Interviewing
- Format: Framework
- Published: 2026-08-19
- Last reviewed: 2026-08-19
- Reading time: 17 min

You just got a take-home assignment and you have to decide, fast, whether to do it, how hard to go, or push back. This guide is for candidates mid-process who want that decision to be defensible instead of a mood. It scores the specific request in front of you against your own leverage and routes you to one of four moves, each with a reason you can say out loud to the recruiter.

The public conversation is useless here. Half of it says never do them; the other half says just do it. Neither tells you how to tell an eight-hour scope-creep trap from a two-hour screen worth taking. The difference is knowable, and it comes down to five factors you can check in under an hour.

## What the four moves are, and when each one is right

The four moves are full effort, hard timebox, counter-proposal, and decline. Each is triggered by a different combination of stage, scope, IP terms, and your leverage, and each carries a reason you can state without burning the process.

The point of naming four moves rather than two is that most take-homes are neither traps nor gifts. They sit in the middle, where the right answer is to do a scoped slice or to counter toward something cheaper for both sides. A blunt yes-or-no throws away that middle ground.

| Move | Trigger signal | Say-out-loud reason |
|---|---|---|
| Full effort | Finalist stage, timeboxed 2 to 4h, clean IP | high intent |
| Hard timebox | Mid-loop, stated hours credible | "I'll deliver a representative slice" |
| Counter | Un-timeboxed or high leverage | "happy to do this live as a case" |
| Decline | Real-company data, week-long, bad IP | capacity plus portfolio redirect |

Read the table as a decision, not a menu. Full effort is for the finalist project a company has clearly invested in reviewing. Hard timebox is the default for a credible mid-loop request: you deliver a representative slice and say so. Counter is for un-timeboxed prompts or when you hold leverage. Decline is reserved for the genuine consulting trap: real company data, a week of work, or ownership terms that hand them shippable output.

> **Rule:** One move, one reason
>
> Every take-home decision resolves to exactly one of four moves, each attached to a reason you would be comfortable saying to the recruiter's face. If you cannot name the reason, you have not finished scoring.

## Why the stated hour count is a signal, not a spec

The number on the prompt tells you more about the team's culture than about the work. Teams that underestimate their own effort project that onto the assignment, so treat the stated hours as a starting hypothesis you verify, never a spec you trust.

Practitioner and vendor guidance converges on a soft ceiling of a few hours, not days. A common range is 2 to 8 hours depending on seniority: 2 to 4 hours for early-stage screens, 4 to 8 hours for more senior roles, and longer only when the assignment is an explicit finalist project or an onsite substitute. A stricter view holds that any assignment over an hour cuts significantly into personal time, and that a company respecting candidates will either scope the work accordingly or set an explicit limit.

Then look at what actually happens. The gap between stated and real is wide and repeats across reports.

| Case | Stated | Actual or estimated |
|---|---|---|
| Datadog SWE | 3 hrs | 5 to 6 hrs expected |
| NYT data science | not stated | ~30 hrs |
| Full-stack containerized app | "couple hours" | ~1 week |
| Signalroster benchmark, senior | - | 4 to 8 hrs |

The Datadog case is the cleanest tell: a stated three hours led to a rejection for "not enough tests," which implies five or six hours were expected. One candidate's read of that pattern was that teams underestimate by five or six times and expect you to compensate with free work. So the first thing you do with the stated number is not believe it.

**~30 hrs - One reported data-science take-home**

A single unpaid assignment can consume close to a full working week; the stated number rarely warns you.

### How to get your own hour estimate

Draft-solve the prompt yourself, or paste it into an AI tool and ask for an estimate of the minimalist solution. If the minimal viable solution does not fit inside the recruiter's stated window, that gap is itself the red flag. You are not looking for a perfect estimate. You are looking for whether the stated number is even in the same order of magnitude as the work.

## The signals that separate a fair exercise from unpaid consulting

An exercise tests whether you can do the job on a fake or unrelated problem. Unpaid consulting extracts work the company can use. The tells are specific and worth memorising, because they are what push a request from timebox to decline.

The clearest red-flag cluster, drawn from candidate reports:

- **Un-timeboxed prompt.** No stated limit means no ceiling on their expectations.
- **High-fidelity work on the company's real problem.** Full responsive design plus a prototype, all selection logic and taxonomy factored in, not an obviously fake project.
- **A presentation on top.** The deliverable plus a full presentation is a common scope multiplier.
- **Real environment or real data.** The hardest tell to spot and the most dangerous.
- **Ambiguous acceptance criteria.** Criteria loose enough to deny you for any reason.

The real-environment tell deserves its own attention because it hides as realism. One candidate reported a task billed at one to two hours that required setting up unfamiliar tooling and submitting a change request in the company's own environment. The setup alone cost five hours. Another described a full-stack, twelve-factor containerized app with API docs that took a week and was rejected with zero feedback. When output plugs into a live environment, you are not being tested. You are producing.

> **Watch out:** Real data is not realism
>
> If the prompt uses the company's production data or its own environment, the output is directly shippable and the IP exposure is at its worst. Read that as a decline signal, not as a sign the company takes the exercise seriously.

The scope multipliers stack. A design take-home that is un-timeboxed, asks for high-fidelity work on a real feature, wants full responsive design plus a prototype, and adds a presentation is four red flags on one prompt. Any one is worth a timebox conversation. All four together is a decline.

## Read the stage before you read the prompt

Where the take-home sits in the loop predicts whether your effort is rewarded or wasted. Effort spent before a human has invested in you carries asymmetric risk, because the reviewer spends minutes on what cost you a weekend.

In a documented flow, a recruiter intro chat precedes the take-home, then a live technical round, then a virtual onsite. That ordering matters. A take-home dispatched right after an automated screen, before any human has spoken to you, is the placement practitioners flag for wasted effort: six hours from you against ten minutes of their review. A take-home that substitutes for the onsite is the opposite. The company is trading its own interview time for your assignment, which is a real investment and usually worth full effort.

#### Where the take-home sits in a typical loop

1. **Recruiter screen** - A human has spent time on you; a take-home here is mid-loop
2. **Take-home dispatch** - Cheapest to send, so watch for pre-screen placement
3. **Live technical round** - Company invests interview time
4. **Virtual onsite** - Finalist stage; a take-home here substitutes for an onsite

*Effort before the first human conversation carries the worst risk-to-reward ratio.*

No public dataset cleanly segments completion-reward by stage, so treat exact percentages as not established. The direction is reliable: earlier placement, before human investment, correlates with wasted effort. Label the stage as pre-screen, mid-loop, or finalist before you do anything else, because it changes the meaning of every other signal.

## The IP and NDA terms you verify before writing a line

Check ownership before you write anything, because an NDA does not protect your work. An NDA governs confidentiality; title to what you create transfers only through a separate assignment clause, and missing that distinction is how candidates hand over shippable IP for free.

Here is the legal spine, stated plainly. NDAs protect confidentiality, not ownership. What transfers title is an assignment or invention-assignment clause, sometimes called a PIIA. So a document can keep your work confidential while still taking ownership of it, or vice versa. Read for the assignment clause specifically.

Two clauses to hunt for:

1. **Broad assignment language.** Wording that assigns everything you create during the relationship, rather than only work directly derived from the confidential information. The guidance for the person doing the work is to push back and limit assignment to derived work.
2. **A residuals clause.** This can let a party recreate your work from memory even without formal transfer. It is a quiet way around ownership limits.

Candidates do encounter these. One reported an interview NDA stating that all work made for the company is theirs. The IP risk is highest exactly when the work is most reusable: real-company-data prompts produce output the company can ship, and an NDA alone will not stop that.

**Written IP confirmation request**

```
Hi [name], happy to take this on. Before I start, can you confirm in writing that the assignment output is used for evaluation purposes only, that I retain all rights and ownership to what I produce, and that nothing here assigns rights to work beyond this exercise? Once I have that I'll get going.
```

*Send before you start. Adapt the role and keep it one paragraph.*

If they will not confirm evaluation-only use in writing, that answer is data. A legitimate exercise has no reason to keep title to a throwaway assignment.

## The procedure: score the request in seven steps

Score the request in order, then route it. Each step ends in a concrete artifact, so you can stop at any point and know exactly what you have decided so far.

#### From prompt to routed decision

1. **Estimate true hours** - Draft-solve or paste the prompt into an AI tool for a minimal-solution estimate. If it does not fit the stated window, that gap is a red flag. Done when you have an estimated-hours number.
2. **Locate the stage** - Confirm whether it comes before a human screen, mid-loop, or as an onsite substitute. Done when you label it pre-screen, mid-loop, or finalist.
3. **Score fidelity and scope** - Flag real-company data, high-fidelity output, un-timeboxed prompts, and added presentations. Done when each signal is marked present or absent.
4. **Check IP and NDA terms** - Verify ownership, residuals, and assignment scope before writing anything. Done when you know who owns the output and have asked for evaluation-only use in writing.
5. **Assess your leverage** - Count live and competing processes and how far you've reached here. Done when leverage is rated low, medium, or high.
6. **Route to one of four moves** - Combine the above into full effort, hard timebox, counter, or decline. Done when one move is chosen and tied to a reason.
7. **Send the message** - For a counter or decline, use a brief, warm script with a substitute offer. Done when the recruiter has a reason you can say out loud and the process is intact.

Two sources disagree on order. Some put the AI scope check first, on the logic that hours dominate the decision. Etiquette guides imply leverage and fit should gate whether you bother estimating at all. My view: estimate first when the request looks reasonable, but if your leverage is high and the prompt is obviously a trap, skip to routing. The steps are a default, not a ritual.

## Assess your leverage, then pick the move

Your leverage is the count of live and competing processes plus how far you have reached in this one. High leverage widens your options toward countering; low leverage narrows them toward doing a scoped version well.

Leverage is not a mood. Rate it against two axes: how far the request pushes you, and how much leverage you actually hold. That gives four zones and a move for each.

#### Routing by scope demand and your leverage

Horizontal axis runs from Reasonable scope to Excessive scope. Vertical axis runs from Low leverage to High leverage.

| Quadrant | What it means |
| --- | --- |
| Reasonable scope, high leverage | Hard timebox; deliver a representative slice and say so |
| Excessive scope, high leverage | Counter to a live case or ask for payment |
| Reasonable scope, low leverage | Full effort if finalist, else a clean timebox |
| Excessive scope, low leverage | Decline with a portfolio redirect, or scope hard and clarify |

*The same take-home routes differently depending on what else you have in play.*

Leverage changes what you can say, not what is true. An un-timeboxed prompt with real data is a bad request whether you have three offers or none. What leverage buys is the room to counter without fear. With competing processes, you can cite them: mention you have an offer with another company, ideally a competitor, and ask to expedite or skip a step. Without them, lead with the substitute rather than the constraint.

> Leverage does not change whether a request is fair. It changes how freely you can say so.

## The counter-proposals that actually get accepted

Three counters recur in candidate reports, and the live-case swap is the strongest because it is cheap for both sides. It satisfies the company's need for a signal without your unpaid weekend, which is why it is reported to land about half the time.

- **Convert to a live walkthrough.** Say on the call that you cannot dedicate time to offline assignments but are happy to work the problem live as a case. Reported to work about 50% of the time.
- **Substitute existing public work.** Send a portfolio or GitHub as proof of work. One candidate did this at two companies and was still considered for the next round.
- **Ask for payment.** Paid take-homes exist. One company paid $500 for a take-home task and no one declined it.

Payment collapses the entire debate. It removes the free-labor objection and self-selects committed candidates, so if a request is paid, weight your decision heavily toward doing it. The decline logic weakens the moment compensation appears.

The live-case counter also fits role type. Engineering candidates can credibly steer toward live coding, which is already integrated into most tech hiring. Product managers face slide and strategy decks that balloon past eight hours, and the larger PM pool means more people hitting that deck trap. Refolk maintains an index of these candidate populations; the scale of who is affected is worth seeing.

**65,557 - US Product Manager profiles in Refolk's index**

Against 28,196 data scientists, a 2.3x larger pool facing the deck-style take-home, per Refolk's index.

| Role | Count | Ratio to Data Scientist |
|---|---|---|
| Product Manager | 65,557 | 2.3x |
| Data Scientist | 28,196 | 1.0x |
| US technical recruiters | 22,994 | - |

In Refolk's index of professional profiles there are roughly 22,994 US profiles with technical-recruiter or talent-acquisition titles. That is the population fielding these declines, and it is worth remembering that a warm, well-scoped counter reads very differently to them than a blunt refusal.

**Live-case counter, sent by email**

```
Hi [name], thanks for this. I'm juggling a few active processes right now, so I can't commit a full offline assignment, but I'd genuinely enjoy working this problem live as a case in a session with your team. Would 45 to 60 minutes work? Happy to send a recent portfolio piece ahead of time so you have context.
```

*Adapt the problem framing to the role; keep it two sentences plus the offer.*

Refolk drafts and tailors these messages against the specific posting and your history, so the counter reads like it belongs in the process rather than a template. If you want to see who fields these decisions on the other side, [Refolk](/candidates) can surface them by role, stage, and location.

Ask me this: `Engineering hiring managers who replaced take-homes with paid or live pair-programming interviews.` - [run the search](https://www.refolk.ai/start?q=Engineering%20hiring%20managers%20who%20replaced%20take-homes%20with%20paid%20or%20live%20pair-programming%20interviews.).

*Returns hiring managers who have publicly moved off offline take-homes, useful for judging whether your counter has precedent at a given company.*

## How this goes wrong: failure modes and false positives

The scoring fails in predictable ways, and each failure has a check. These are the most valuable part of the standard because they are where a defensible decision quietly becomes a bad one.

- **Trusting the stated hour count.** The false positive is "2 to 3 hours, easy" that is really ten-plus. Check: run the minimal-solution estimate before committing anything.
- **Over-delivering to signal commitment.** Twelve hours on a four-hour task signals poor scope management, not commitment. Check: timebox, and state the slice you scoped so the discipline reads as a feature.
- **Under-delivering on a legitimate finalist project.** A reflexive minimal effort when the company is investing equally costs real opportunities. Check: confirm the stage before routing, and give a finalist project full effort.
- **Assuming an NDA protects your IP.** Signing believing confidentiality equals ownership. Check: look for the assignment and residuals clauses, not just the confidentiality language.
- **Missing the real-company-data tell.** Reading production data as realism. Check: ask whether the output plugs into their live environment; if it does, treat it as a decline signal.
- **A counter read as inflexibility.** A blunt no that ends the process. Check: always pair the decline or counter with a live-case or portfolio substitute.
- **Believing an ambiguous rubric is knowable.** Criteria loose enough to deny you for any reason. Check: ask one concise clarifying question up front, and note whether the answer sharpens the target.

The two most expensive errors sit at opposite ends. One is over-delivering on a trap; the other is under-delivering on a genuine finalist project. Both come from skipping the stage check. Locate the stage first and most of these failures never trigger.

> **Tip:** One clarifying question is free intelligence
>
> Ambiguous acceptance criteria are a red flag, but a single concise question up front does double duty: it sharpens your target and shows you how the team communicates. A vague or evasive answer is itself a scoring input.

## Keep the decision current as the process moves

Re-score whenever a new fact lands, because leverage and stage both move under you. A competing offer, a shift from mid-loop to finalist, or an NDA arriving late all change the right move even if the prompt has not changed a word.

Before you commit to your move, run this final check.

#### Before you reply

- [ ] You have an estimated hours number and compared it against the stated one.
- [ ] You have labelled the stage pre-screen, mid-loop, or finalist.
- [ ] Every fidelity and scope red flag is marked present or absent.
- [ ] You know who owns the output and have asked for evaluation-only use in writing.
- [ ] Your leverage is rated low, medium, or high against live processes.
- [ ] You have chosen exactly one of the four moves.
- [ ] Your message pairs any decline or counter with a substitute offer.
- [ ] You can state your reason out loud without negative commentary.

The hour benchmarks, the red-flag list, and the legal distinctions are stable; they describe mechanisms, not moments. What changes is the specific request and your position around it. Score the request in front of you, route it to one move, and keep the reason short enough to say in one breath. That is what makes the decision defensible instead of a rant in either direction.

## Frequently asked questions

### Should I do a take-home assignment or is it a red flag?

Do it when the request is timeboxed to a few hours, sits at a stage where a human has already invested in you, uses a fake or unrelated dataset, and leaves you owning your work. Treat it as a red flag when it is un-timeboxed, asks for high-fidelity production output, plugs into the company's real environment or data, or arrives before any human screen. The request itself is neutral. The scope and terms decide it.

### How many hours should a take-home interview take?

Practitioner guidance converges on 2 to 4 hours for early-stage screens and 4 to 8 hours for senior roles, with a stricter view that anything over one hour cuts significantly into personal time. Longer is defensible only when the assignment is an explicit finalist project that substitutes for an onsite. Estimate the minimal solution yourself before trusting the stated number, since reports of a stated 2 to 3 hours becoming 10 to 30 are common.

### How do I decline a take-home assignment politely without ending the process?

Keep it brief and warm, and always pair the decline with a substitute. Offer to work the problem live as a case, or send existing public work such as a portfolio or GitHub. You do not need to give extra detail or negative commentary. One candidate declined at two companies by sending proof of work and was still considered for the next round, and the live-case counter is reported to work about half the time.

### Can I counter with a live interview instead of a take-home?

Yes, and it is often the strongest move. Say on the call that you cannot dedicate time to offline assignments but are happy to work the problem live as a case. This satisfies the company's need for a signal without your unpaid weekend, which is why it is reported to land about 50% of the time. For engineering roles it is especially credible, since live coding is already in most tech hiring processes.

### Does an NDA on a take-home mean the company owns my work?

No. An NDA protects confidentiality, not ownership. Title transfers only through a separate assignment or invention-assignment clause, so read for that specifically and for a residuals clause, which can let a party recreate your work from memory. Ask in writing that the output be used for evaluation only and that you retain all rights. IP risk is highest when the prompt uses real company data, because that output is directly reusable.

### Is a paid take-home worth doing?

Usually yes. Payment removes the free-labor objection and self-selects committed candidates. In one reported example a company paid $500 for a take-home and no one declined it. Compensation weakens the entire case for declining, so if a request is paid, weight your decision toward doing it and reserve pushback for genuine scope or IP problems.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/candidates/guides/take-home-request-scored*