# The Take-Home Assignment, Carried From Prompt to Submitted Deliverable

*You will be able to scope a take-home under its clock, cut requirements on purpose, and submit a runnable deliverable with a note that reads as judgment, not an unfinished draft.*

- Canonical URL: https://www.refolk.ai/candidates/guides/take-home-assignment-prompt-to-deliverable
- Pillar: Interviewing
- Format: Teardown
- Published: 2026-08-13
- Last reviewed: 2026-08-13
- Reading time: 18 min
- Keywords: how to do a take home assignment, take home coding challenge time limit, what to include in take home submission, take home assignment scope too big, take home assignment readme notes

## Key takeaways

- A common reported technical scoring split is 40% correctness, 30% code quality, 20% communication, and 10% polish, so a clear reviewer note is not garnish - it is roughly a third of the score.
- Runnability is a gate, not a score line: failed setup can get a submission thrown out before the code is read, and un-runnable code is graded Ungradable in a documented CS rubric.
- Reviewers spend about 10 to 15 minutes per submission, so the note is what they actually read; an opaque but correct build can lose to a clearer, weaker one.
- Over-building is a negative signal, not neutral effort - reviewers rarely want 12 files or 3,000 lines, and one GitHub case shipped clean code at 75% coverage and was still rejected.
- The identical cut list reads as unfinished or deliberate depending on wording; a 'with more time' section converts an omission into evidence of judgment.
- Community reports consistently describe multiples, not overruns: tasks pitched at 2 hours realistically take 4 to 6 or more for a senior engineer.

You have a take-home with a stated time limit, and you need to decide what to build, what to cut, and what to submit so it scores as a pass. This guide is for candidates in the interview loop who are staring at a prompt and a clock right now. It carries one engineering assignment from prompt to submitted deliverable, showing the real fork-by-fork scoping decisions, including the wrong turns, so you can follow along on your own case.

The library already covers whether a take-home is fair to accept and how to decode assessment types. This is the one document that runs a single assignment through execution under its clock: which requirements to build, which to stub, which to skip, and the exact note that turns an incomplete-looking submission into a deliberate one.

## The worked example, and why it is an engineering take-home

The example carried through this guide is a backend take-home: a REST API with two endpoints, tests, and a README, stated at 2 hours. I chose an engineering case because the audience is heavily engineering-weighted. In Refolk's index of professional profiles, US Software Engineer profiles outnumber Data Scientists by roughly twelve to one.

That ratio is worth seeing before you scope anything, because it tells you how many other people are being measured on the same rubric.

| Role | Profiles | Ratio vs Data Scientist |
|---|---|---|
| Software Engineer | 348,829 | 12.1x |
| Product Manager | 66,558 | 2.3x |
| Data Scientist | 28,766 | 1.0x |

Profile counts come from Refolk's index. The ratio column is derived by division. The point is not the exact figure; it is that an engineering take-home is graded inside the largest, most standardized pool, so the reviewer's shortcuts are the ones documented here. Data science and product take-homes follow the same shape with different deliverables, and I flag those variants where they diverge.

**348,829 - US Software Engineer profiles in Refolk's index**

About 12x the Data Scientist pool, which is why the worked example is an engineering take-home.

The prompt for our example reads: "Build a REST API with two endpoints. Include tests and a README. Timebox: about 2 hours. Submit a link to a Git repository." That is the whole prompt. Everything below is what I do with it.

## What the reviewer is actually scoring

The reviewer is scoring correctness, code quality, communication, and polish, in that order of weight, and they are doing it in about 10 to 15 minutes. One recruiting-focused source states a concrete split for technical roles: 40% correctness, 30% code quality, 20% communication, and 10% polish. For non-technical roles the weighting shifts toward judgment and clarity.

Treat that split as directional, not authoritative. It comes from a single vendor blog, not an industry body. But the mechanism behind it is well supported: a candidate who explains a tradeoff well can outperform someone who is technically stronger but opaque.

| Dimension | Reported weight | What it means for your hours |
|---|---|---|
| Correctness | 40% | Required features must run end-to-end. This is the largest build block. |
| Code quality | 30% | Readable, tested, no dead surface area. Partly earned in validation. |
| Communication | 20% | Your README and reviewer note. Cheap to earn, easy to skip. |
| Polish | 10% | Formatting, extras. Last, and only if the core is complete. |

Two things fall out of this table. First, communication is roughly a fifth of the score on its own, and it bleeds into code quality too, so the note is not optional garnish. With reviewers spending only 10 to 15 minutes, the note is what they actually read. An opaque but correct submission can lose to a clearer, weaker one.

Second, polish is worth 10%. If you are formatting output while a required endpoint is unbuilt, you are trading a 40-point line for a 10-point one.

**10-15 min - Time a reviewer spends per submission**

The note and README are what they read in that window, not every line of code.

## The four phases, and where each hour goes

The strongest submissions follow four phases in order: clarify, scope, execute, package. This keeps you from overbuilding and makes the work easier to review, so every hour has a purpose. A precise minute-by-minute template is not established publicly. Sources give phase order, not fixed fractions, so treat the percentages below as a starting split you adjust to your prompt.

#### The four phases of a take-home

1. **Clarify** - Read the prompt twice, mark required vs extra, ask at most one question.
2. **Scope** - Write one paragraph naming what you will and will not build.
3. **Execute** - Build required items to end-to-end, then validate with tests.
4. **Package** - README, clean-machine test, and the reviewer note.

*Clarify and scope are cheap and front-loaded; execute is the largest block; package is where the score is often won or lost.*

Front-loading planning pays back directly: the more time you spend up front planning, the less time you spend writing code. For a 2-hour stated budget that realistically runs to 4 to 6 hours, I plan against the real number and hold the line on scope so the deliverable is complete at whatever hour I stop.

Here is how I split a working budget. Call the total T, whatever T turns out to be:

- Clarify: 15 to 30 minutes. Extract requirements, send one question.
- Scope: 15 minutes. Write the scope paragraph.
- Execute, core build: roughly half of T. Required features only.
- Execute, validation: 20 to 25% of T. Tests and edge cases on the core.
- Package: 30 to 60 minutes. README, clean-machine test, reviewer note.

The rule that governs the transitions: when the core-work block ends, stop adding features and move to polish. A complete, well-tested submission beats an ambitious half-finished one.

> **Rule:** The core is done before any polish
>
> Do not touch formatting, extra endpoints, or nice-to-haves until every required feature runs end-to-end. Polish is worth about 10%; the required features are worth about 40%.

## The step-by-step, carried through the example

Below is the procedure applied to the REST-API prompt. This is the machine-readable spine of the guide; follow it in order on your own case.

#### From prompt to submitted deliverable

1. **Extract required vs extra** - Read the prompt twice and mark every requirement required, nice-to-have, or extra-credit. Confirm you are not starting from the extra-credit items.
2. **Send one clarification message** - Ask one concise question about hour target, format, and AI-tool policy, then proceed. Done when you have a target and format, or have decided your assumptions are safe.
3. **Write a scope statement** - Name in one paragraph what you will and will not build. Done when in-scope and out-of-scope are both explicit.
4. **Build the required items** - Spend roughly half the budget getting required features to run start to finish. Done when the core runs end-to-end with nothing required missing.
5. **Validate the core** - Spend a fifth to a quarter of the budget on tests and edge cases on the core only. Done when a fresh checkout passes.
6. **Cut and stub at the buzzer** - When the core block ends, stop adding features and convert remaining nice-to-haves into stubs or a cut list. Done when every unbuilt item is stubbed or named.
7. **Package with README and clean-machine test** - Write a README with exact versions and one run command, then run only that command on a fresh machine. Done when someone could run it blind.
8. **Write the reviewer note** - Summary, assumptions, tradeoffs, cut list, and a with-more-time section. Done when a reviewer skimming for 10 to 15 minutes finds your reasoning fast.

### Walking it on the example

**Extract.** The prompt has three explicit requirements: two endpoints, tests, a README. Implied requirements: the API should actually start, and the repo should be laid out so a reviewer can find things. Nothing is marked extra-credit here, which is good; the common trap is starting from goals marked "extra points" instead of the main requirements.

**Clarify.** I send one message: "Confirming the target is roughly 2 to 4 hours, that you want a Git repo link, and whether AI coding tools are permitted." That is the whole message. Sources disagree on whether to ask at all - some say ask first, others say make reasonable assumptions and avoid asking. The reconciliation is to cap at one concise question and proceed regardless of the reply timing.

**Scope.** I write: "I will build a REST API with two endpoints, unit tests covering the core paths, and a README with setup and a single run command. I will not implement authentication, a frontend, or a database beyond an in-memory store." That paragraph is the contract I hold myself to for the rest of the clock.

> The scope paragraph is a contract with yourself; without it, every nice-to-have looks like a requirement at hour three.

**Core build.** Roughly half the budget goes to both endpoints working end-to-end with the in-memory store. First working solution first: reviewers prefer one clean working solution over two half-baked ones.

**Validate.** A fifth to a quarter of the budget goes to tests on the two endpoints and a couple of edge cases: empty input, malformed request. I check that a fresh checkout passes.

**Cut and stub.** The buzzer rings before I add persistence. So persistence becomes a cut-list line, not a half-built feature. Auth was already out of scope. A pagination stub gets a one-line comment instead of an implementation.

**Package and note.** Covered in the next two sections, because they are where most submissions are won or lost.

## The fork nobody scopes for: an unrealistic budget

When the stated budget is a fraction of the real one, the safe move is a scoped partial plus a note, not a request for more time. There is no clean answer to this fork, because the same act is read oppositely by different readers.

The gap is well documented. Practitioner reports describe multiples, not overruns.

| Format | Stated | Reported actual |
|---|---|---|
| Senior full-stack | ~2 h | 4 to 6+ h |
| GitHub SWE | ~2 h (5 h cap) | 3 h submitted, rejected |
| Data science (NYT) | not stated | ~30 h |

All values are as reported by named practitioner posts and are not independently verified. A rigorous cross-format study is not established publicly. But the pattern - "they said two hours, it took ten" - is exactly what community threads keep describing.

You have three documented moves when the budget is clearly too small:

1. **Ask one scoping question up front.** Confirm the hour target and format. When in doubt, ask one concise clarification question and move forward.
2. **Decline or cap.** Engineers report capping their effort at 3 to 4 hours and declining assignments longer than that.
3. **Submit a scoped partial with a note.** The middle path, and usually the right one.

The tension is real. Asking, or requesting an extension, signals judgment to candidate-side writers and weak time management to employer-side ones. If candidates scramble, ask for an extension, or submit poor-quality work because they ran out of time, some employers read that as a concern about time management. So do not lean on an extension to buy silence. If you request one, pair it with a working partial so the request reads as calibration, not rescue.

> **Watch out:** An extension request can cut against you
>
> Only request more time if the scope is genuinely unrealistic, and always pair it with a partial submission. To some employers a bare extension request signals weak time management, not diligence.

The GitHub case is the cautionary one. A candidate submitted in 3 hours against a 5-hour cap with about 75% test coverage and was rejected. The lesson is not "spend more time." It is that finishing the required set 100% matters more than partial coverage of an ambitious surface, and that polishing before the core is complete is a losing trade.

## The two defects that get you rejected before the code is read

Runnability and format compliance are gates, not score lines. If your submission fails to set up, it can be thrown out automatically before any code is read. The review only starts if the app starts.

This is the highest-leverage insight in the whole guide. A guide states plainly that if setup fails it gets thrown out, and that you fix this by including a README naming exact software versions and a single start command, then testing it on a fresh computer before sending. A documented CS rubric mirrors this: broken code that cannot be run with a few simple fixes drops to Needs Improvement, and if it cannot be made to work it is Ungradable.

So a fresh-machine test buys more marginal pass-probability than any feature you could add in the same time. Clone to a clean container, run only the README command, and watch it fail on the environment variable you forgot to document. That is the whole point of the exercise.

Format non-compliance is the second gate. Wrong repo layout, wrong zip name, a PDF where they asked for a repo. These are treated as a filter. Read the exact submission instruction line before you send.

## How this goes wrong: the failure modes

Most take-home failures are not about skill. They are predictable, and each has a tell. Here are the ones documented in practice, with what each looks like when it lies to you and how to check.

- **"It runs on my machine."** The false positive: it passes locally because of an uncommitted environment variable or a missing manifest. Check by cloning to a clean container and running only the README command.
- **Over-building.** The false positive: you feel productive shipping 3,000 lines, and the reviewer reads it as poor prioritization. Reviewers rarely want 12 files and 3,000 lines. Check that every file maps to a stated requirement; if it does not, cut or stub it.
- **Polishing before the core is complete.** The GitHub case shipped clean code at 75% coverage and still failed. Check that the required feature set is 100% done before any polish.
- **Silent assumptions.** The false positive: you "handled" ambiguity by guessing but never wrote it down, and the reviewer reads it as a miss. Check that every assumption appears in the note.
- **Cut list framed as an apology.** "I didn't finish X, Y, Z" reads as unfinished; the identical content framed as "deliberately out of scope, and here is why" reads as judgment. One candidate shipped a cut list and still felt it guaranteed rejection, so framing is load-bearing.
- **Asking too many clarifying questions.** You think you look thorough; some reviewers want you to decide. Cap at one concise question, then proceed.
- **Format non-compliance.** Wrong repo layout, zip name, or format. Check the exact submission instruction line before sending.

#### Effort placement, and what to do about it

Horizontal axis runs from Not required to Required. Vertical axis runs from Low polish to High polish.

| Quadrant | What it means |
| --- | --- |
| Skip it | Unrequired and rough - a cut-list line, nothing more. |
| The trap | Polished but unrequired - reads as poor prioritization. Cut it. |
| Stub or note | Required but rough - stub it and name it in the note. |
| Where you win | Required and polished - the core, done and tested. Spend here. |

*Effort only pays when it lands on a required, graded surface; the other three quadrants cost review time without buying score.*

Over-building deserves its own emphasis because it feels like virtue. Extra surface area adds review cost without adding graded signal. If a file does not map to a stated requirement, it is working against you, not for you.

## The reviewer note that reads as a pass

The reviewer note is where you convert an omission into evidence of judgment. Listing what you cut is advised, not hidden, because the same cut list reads as "unfinished" or "deliberate" depending entirely on how you frame it.

The recommended spine is an executive summary, approach and assumptions, results, limitations and next steps, plus a README explaining the problem, solution, how to run it, and the tradeoffs. Practitioners specifically endorse a "with more time" section: leave comments about tradeoffs and complexity, and include a section on what you would have done with more time, such as more tests or another edge case. This matters because the follow-up interview often asks exactly that - what you would do with 10 to 20 more hours.

Stating assumptions deliberately reads as judgment: it is okay to proceed with an assumption as long as you state it clearly, which shows you navigated uncertainty deliberately instead of ignoring it.

**Reviewer note skeleton**

```
## Summary
What I built, in two sentences, and how to run it.

## Assumptions
- [Ambiguity in the prompt] -> I assumed [X] because [reason].
- [Second ambiguity] -> I assumed [Y].

## What's included
- [Required item 1] - done, tested.
- [Required item 2] - done, tested.

## Deliberately out of scope
- [Cut item] - out of scope for this timebox. I would add it by [approach].
- [Second cut item] - stubbed; see [file/line] for the seam.

## With more time
- [Next test or edge case I'd add first, and why]
- [The refactor or feature I'd reach for next]

## Run it
Versions: [language X.Y], [runtime X.Y]
Command: [single start command]
Tested on a fresh checkout.
```

*Paste at the top of your README or as a NOTES.md. Keep it to one screen; the reviewer has 10 to 15 minutes.*

Notice the framing. There is no "I didn't finish." There is "deliberately out of scope," followed by how you would do it. That single wording change is the difference between a draft and a decision.

The README itself has a documented structure: Installation, Usage, Design Decisions, Future Improvements. For a PM take-home the deliverable spine differs - Assumptions, Target Users, What and Why, Goals and Metrics, Wireframes, Tradeoffs, Risks - but the principle is identical: state your assumptions, name your cuts, and make your reasoning findable fast.

> **Tip:** Write the note last, but keep a running scratch file
>
> Jot each assumption and each cut the moment you make it, in a scratch file. At package time the note assembles itself instead of forcing you to reconstruct decisions you've already forgotten.

## Before you submit: the final check

Runnability and format compliance are gates. Communication is a graded line. This checklist covers both. Do not call the assignment done until every item is true.

#### Pre-submit verification

- [ ] Every required item from the prompt is built and runs end-to-end.
- [ ] A fresh checkout or clean container runs using only the README command.
- [ ] The README names exact software versions and a single start command.
- [ ] Every file maps to a stated requirement; unrequired surface area is cut or stubbed.
- [ ] Every assumption I made is written in the reviewer note.
- [ ] The cut list is framed as deliberate scope, with how I'd add each item.
- [ ] There is a "with more time" section naming what I'd do next.
- [ ] The repo layout and submission format match the exact instruction line.

If you want to see how reviewers on the other side think before you submit, it helps to read what they publish. You can find the people who grade these assignments and write about their standards, then reverse-engineer what a pass looks like from their own words.

Ask me this: `Hiring managers or engineering leads who review take-home assignments at Series B fintechs` - [run the search](https://www.refolk.ai/start?q=Hiring%20managers%20or%20engineering%20leads%20who%20review%20take-home%20assignments%20at%20Series%20B%20fintechs).

*Returns reviewers who set and grade take-homes, so you can read how they describe a strong submission before you write yours.*

## Keeping this current for the next assignment

Every take-home is different, so the way to keep this guide useful is to re-derive the scope split from each new prompt rather than reuse the last one. The phase order - clarify, scope, execute, package - holds across formats. The fractions do not.

Two things are worth re-checking each time. First, the scoring weighting. The 40/30/20/10 split is from a single vendor blog and is directionally useful, not authoritative; if the prompt or recruiter tells you what they weight, use that instead. Second, the AI-tool policy, which changes by company and belongs in your one clarification question every time.

Tools like [Refolk](/candidates) write your resume from your own history and tailor it to each posting, which frees the hours the take-home is going to eat. When you reach the assignment itself, the method above is the durable part: build the required set to 100%, cut the rest on purpose, test on a clean machine, and write the note that makes your reasoning findable in the 10 to 15 minutes a reviewer actually spends. Do that and a scoped partial reads as a strong pass, not an unfinished draft.

## Frequently asked questions

### They said two hours but it clearly takes ten. What do I actually do?

Do not try to finish it in two. Community reports consistently describe multiples: a 2-hour task realistically takes 4 to 6 or more hours for a senior engineer, and worst cases reached about 30 hours. Scope to the required items, build one clean working solution, and submit a scoped partial with a note that names what you deliberately left out. Requesting an extension can read as weak time management to some employers, so pair any ask with a working submission rather than using it to buy silence.

### What should I include in a take-home submission besides the code?

Include a README and a short reviewer note. The README should name exact software versions, a single start command, and design decisions. The note should carry an executive summary, your assumptions, results, tradeoffs, a deliberate cut list, and a 'with more time' section. With reviewers spending only 10 to 15 minutes and communication worth roughly a fifth of the reported score, this text is what they actually read.

### Is it better to submit incomplete or ask for more time?

Submit a scoped partial with a note. The same act of asking reads as judgment to some sources and as weak time management to employer-side ones, so there is no clean win in requesting time. A complete, runnable, well-tested core plus a clear cut list beats an ambitious half-finished build, and it keeps the decision in your hands rather than the recruiter's.

### How do I keep my take-home from getting auto-rejected on setup?

Test it on a fresh machine or a clean container before sending, running only the command in your README. Failed setup can get a submission thrown out automatically, and un-runnable code is graded Ungradable in a documented CS rubric. The review only starts if the app starts, so a clean-machine test buys more marginal pass-probability than any extra feature.

### Should I ask clarifying questions or just make assumptions?

Cap it at one concise question, then proceed on stated assumptions. Some reviewers want you to ask; others want you to decide. The safe path is a single question about hour target, format, and AI-tool policy, and then documenting every judgment call in your note so ambiguity you navigated reads as deliberate rather than as a silent miss.

---

*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-assignment-prompt-to-deliverable*