# The Take-Home, Carried From Prompt to Sent Submission

*You can carry a take-home from prompt to sent submission on budget, deciding what to build, what to cut, and how to document it so the key decision is found in two minutes.*

- Canonical URL: https://www.refolk.ai/candidates/guides/take-home-prompt-to-submission
- Pillar: Interviewing
- Format: Teardown
- Published: 2026-09-16
- Last reviewed: 2026-09-16
- Reading time: 16 min

You have a take-home assignment in your inbox and a clock running. This guide carries one through, hour by hour, from the emailed prompt to a sent link, including the wrong turn into gold-plating an approach that got abandoned and the scope cut that saved the deadline. It is for candidates who already accepted the take-home and now have to build it, on the stated budget, without over-spending into a negative signal.

The worked case: a three-hour backend prompt, "build a small service that ingests a CSV of orders and exposes a totals endpoint," 48-hour calendar window. I will use it to show where the real decisions sit. Your prompt will differ; the forks will not.

## What the reviewer actually does with your submission

A reviewer opens the README first, tries to run the code, and spends ten to twenty minutes total on the whole thing. That is the fact the entire format bends around: you spend hours building, and the person judging it spends minutes reading.

The numbers cluster tightly across sources. f1jobs puts a first pass at three to eight minutes. SignalRoster says five to ten. rankid says ten to twenty total, README first. askcruit frames it as a "five-minute test" where reviewers try to run your code and toss it if it needs manual setup.

| Source | First-pass minutes |
|---|---|
| f1jobs | 3-8 |
| SignalRoster | 5-10 |
| rankid | 10-20 (total) |
| askcruit | "a few" (five-minute test) |

The midpoint across the numeric sources is roughly nine minutes. Design for nine minutes. The implication is uncomfortable but freeing: the README is the only artifact guaranteed to be read in full, so it carries weight out of all proportion to the time it takes to write. This is a mechanism, not a preference. Time scarcity forces the reviewer to the document that summarizes your judgment, and away from the lines of code that took you all afternoon.

**9 min - Midpoint of a reviewer's first pass across three sources**

Design your README and run instructions to survive a nine-minute skim, not a full read.

## The budget is half build, and the stated number is a trap

Roughly half of your time budget is for building. The other half goes to testing the risky part, writing the README, cleaning up, and verifying the thing runs from a clean clone. That split is the entire discipline of this format.

rankid is concrete: on a 180-minute budget, spend 30 minutes on the README, and treat only about half the total as build time. f1jobs allocates a fixed 15-minute review-and-cleanup step that does not scale down for shorter projects. So on my three-hour case, the shape is: about 90 minutes building, and the remaining 90 spread across setup, one test, the README, cleanup, and the runnability check.

Now the trap. Authors reliably under-estimate their own prompts by about 2x. A candidate who spends the "stated" four hours is often already at the author's real expectation. Overshooting from there is exactly where the negative signal begins. A FAANG manager put the ceiling in one line: it is okay to spend six hours on a four-hour assignment, but if you spend forty it will be obvious.

| Source | Early/screen | Senior | Ceiling advice |
|---|---|---|---|
| CodeSubmit | 2-4 h | - | recommends 2-4 h |
| SignalRoster | 2-4 h | 4-8 h | "if 2h, don't spend 8" |
| f1jobs | 2-6 h (typical) | 2-6 h | more rarely helps |
| rankid | - | - | 3 h unpaid ceiling |

Read the table as a range, then pick the low end of your role's band as your working target. For my three-hour case that is the ceiling rankid recommends for anything unpaid, and I hold to it.

> **Rule:** Time-log yourself from minute zero
>
> Start a timer when you open the prompt and record it in the README. Reviewers compare your submission against the stated budget, and a build that clearly took three times as long signals someone who cannot scope work.

## The one-case time log, fork by fork

Here is the actual log from the three-hour case, including the wrong turn. Read it as the shape you are trying to hit, not a script to copy minute-for-minute.

#### The three-hour take-home, as it actually ran

1. **0:00-0:18** - Read the prompt twice, wrote acceptance criteria and the cut list
2. **0:18-0:35** - Mapped the repo, got a bare service running clean
3. **0:35-1:20** - Built the CSV ingest and totals endpoint - core path end to end
4. **1:20-1:55** - Wrong turn: started a streaming parser for "large files" nobody asked for
5. **1:55-2:35** - Cut the streaming code, one test on the totals math, README
6. **2:35-3:00** - Linter, cleanup, fresh clone, ran it, pushed the link

*Half the clock went to building; the wrong turn and the recovery both happened inside the build block.*

The fork worth studying is at 1:20. The core path worked. The prompt said nothing about file size. I convinced myself that a "real engineer" would stream the CSV to handle gigabyte inputs, and spent 35 minutes on a parser I did not need. This is gold-plating, and it is the single most common failure mode in the format. It stems from good intentions, wanting to overdeliver or show craftsmanship, but without alignment to the brief it is complexity for no return.

At 1:55 I made the recovery decision: delete the streaming code entirely and write one sentence in the README instead. "I read the whole file into memory because the sample dataset is small; for production inputs above memory I would stream and note the tradeoff." That sentence is worth more than the parser, because the reviewer can grade a decision in seconds but must debug a half-feature. The 35 minutes were not free, they ate into my test and cleanup time, but the cut saved the deadline. If I had shipped the half-finished parser, I would have left dead code from an abandoned approach, which reads as noise, and I would have owned a build that overshot the budget for a feature nobody wanted.

> A reviewer grades a decision in seconds but must debug a half-feature, so name the cut and move on.

## The procedure, prompt to sent link

This is the sequence. Steps 1 and 2 are cheap and save you from the expensive mistakes later. Note the order dispute on the cut list: rankid and f1jobs sometimes draft the README first as a forcing function, while four-leaf puts the cut decision first. I put the cut list first because writing down what you are not building is the fastest way to stop yourself gold-plating at hour two.

#### Carry the take-home from prompt to submission

1. **Read the prompt twice and record the budget** - Read it through twice, write down the stated time budget in minutes, and email to ask if none is stated. Translate the prompt into acceptance criteria, separating explicit requirements from optional improvements.
2. **Decide the cut list before writing code** - Write down what you are deliberately not building and why, before touching the editor. This list becomes the spine of your README.
3. **Map the repo and set up the boilerplate** - Confirm the toolchain runs, find the entry point, and locate the module your change touches. Get the project compiling and running clean before adding a line.
4. **Build the core path end to end** - Build the narrow success path all the way through before adding anything around it. Spend roughly half the total budget here and no more.
5. **Test the risky part only** - Write one or two tests on the logic where correctness is genuinely at risk, and skip blanket coverage on trivial code on purpose. Note what you left untested and why.
6. **Write the README** - Lead with what you built and what you would do next, then assumptions, run instructions, and the cut list. Budget about one-sixth of the total to this.
7. **Review and clean up** - Delete dead code from any abandoned approach, fix inconsistent naming, and run the language's formatter and linter.
8. **Verify runnability and submit** - Clone the repo fresh into a new directory, run the exact command in your README, and confirm it starts on the first try. Then push or send the link.

On step 5, the test choice is itself a signal. Blanket coverage on trivial code is box-ticking; one well-chosen test on the tricky logic is judgment. In my case the risky part was the totals math, especially around orders with zero quantity and duplicate order IDs. I wrote one test on that, and wrote in the README that the HTTP layer was left untested on purpose because it was thin routing. That is a defensible choice you can explain in the debrief. Which matters, because the debrief tests exactly the code you shipped, and if you built something you cannot explain, you will not advance.

## What goes in the README, and where the decision lives

Lead with what you built and what you would do next. Those two lines, in the first paragraph, are what the reviewer reads in the nine-minute pass, so a strong submission is organized so the interesting decision is findable in under two minutes.

The fixed, non-optional components are consistent across every serious source: the outcome up top, listed assumptions, a "what I would do next with more time" section, exact installation and run instructions with named dependencies, and the cut list with a one-line reason per omission. Testing a challenge without run instructions is frustrating and time-consuming, and frustrated reviewers toss submissions.

**README skeleton for a take-home submission**

```
# Orders Totals Service

## What I built
A service that ingests a CSV of orders and exposes a /totals endpoint returning
per-customer sums. Core path works end to end.

## What I'd do next with more time
Stream the CSV parser for inputs larger than memory; add auth on the endpoint.

## Run it
- Requires: <language + version>, <one package manager>
- Install: <one command>
- Start: <one command>
- Test: <one command>

## Assumptions
- Sample dataset fits in memory, so I read the whole file (not streamed).
- Duplicate order IDs are summed, not deduplicated. Flag if that's wrong.

## What I deliberately left out, and why
- Pagination: dataset is small; a full response is simpler to review.
- HTTP-layer tests: thin routing, low correctness risk. Tested totals math instead.

## Time spent
~3 hours against a stated 3-hour budget.
```

*Fill each section in order; the first two lines are what a nine-minute reviewer reads.*

Silent assumptions are their own failure. Solving an ambiguity in your head and never writing it down is a false positive: you feel you handled it, but the reviewer sees an unexplained choice. If something essential is ambiguous, ask the recruiter or document a reasonable assumption in the README. The duplicate-order-ID line above is exactly that: a place where the prompt was silent and I made a call in writing.

## How this goes wrong, and how to catch each one

The failure modes are predictable, which is good news, because you can check for each before you submit. Every one has a false positive that feels like success while you are doing it. Here is what each proves and what it looks like when it lies to you.

- **Over-spend read as under-skill.** A polished 12-hour build on a 4-hour prompt feels like dedication to you. To the reviewer it signals someone who cannot scope, since scoping is most of what senior roles are. The catch: your own time log, and the stated budget written in the README.
- **Empty README, "the code speaks for itself."** Most candidates treat the take-home like homework, do the minimum spec, and leave the README empty. The code does not speak for itself in a nine-minute pass. The catch: can a stranger find your key decision in two minutes?
- **Doesn't run on clone.** "Works on my machine" is the classic false positive, because your machine holds installed state and environment variables a clean checkout does not. If it needs manual setup, it gets tossed. The catch: run it from a fresh clone in a new directory.
- **Gold-plating an abandoned approach.** Dead code from a wrong turn, like my streaming parser, reads as noise and inflates your apparent time spent. The catch: grep for anything the success path does not call, and delete it.
- **Blanket trivial tests instead of one meaningful one.** A wall of tests on getters and setters looks thorough but signals box-ticking. The catch: point to the one test on the logic that could actually be wrong, and say the rest was skipped on purpose.
- **Reaching for an unfamiliar framework to look current.** Novelty produces code that looks unpracticed because it is, and reviewers can tell. The round rewards fluency, not the newest tool. The catch: build in the stack you know cold.
- **Can't defend it live.** The debrief tests exactly the code you shipped. If you cannot explain a line, you built the wrong thing. The catch: read your own diff aloud before submitting and flag anything you would stumble on.

> **Watch out:** Gold-plating is the failure that feels like the win
>
> The urge to overdeliver is where good candidates lose. Adding features they did not ask for is over-engineering; keep any surplus effort in the written summary, not in code. If you catch yourself building for a requirement the prompt never stated, that is your cut-list cue.

The matrix below is the judgment call at every fork: is this scope in the prompt, and is it cheap? Only one quadrant is a clear "build it now."

#### The build-or-cut decision at every fork

Horizontal axis runs from Out of scope to In the prompt. Vertical axis runs from Cheap to build to Expensive to build.

| Quadrant | What it means |
| --- | --- |
| Cheap, out of scope | Skip it; do not let it creep in |
| Cheap, in scope | Build it now, it is core |
| Expensive, out of scope | Cut it; one README sentence on what you would do |
| Expensive, in scope | Build the narrow version, name the fuller one as next steps |

*The only clear build is in-scope and cheap; everything else is a README sentence or a deliberate cut.*

## Submit it so it runs on the first try

Submit via a git host with run instructions in the README, or a ZIP in third-party storage with the same. Both are standard: algocademy names the GitHub repo with README setup as the default, and Spawning accepts either a public repo link or a ZIP. GitHub itself runs anonymized, PR-based take-homes with automated tests and a rubric. The strongest submission is the smallest complete change that satisfies the brief and is easy to review, delivered as a reviewable diff.

Before you push, two mechanical checks that cost almost nothing and signal professionalism. Run the language's formatter and linter: Prettier and ESLint for JavaScript or TypeScript, Black or Ruff for Python. And organize by responsibility, because a project that puts all logic in one 400-line file is a red flag. Split by what each module does, even in a small project.

Then the runnability check, which is non-negotiable. Your code must run right away. Clone the repo into a directory you have never worked in, run the exact command from your README, and watch it start. If it needs a step your README does not list, add the step. Do this last, after cleanup, so you are testing the thing you are actually sending.

#### Before you send the link

- [ ] The stated budget is written in the README and my time roughly matches it
- [ ] The README opens with what I built and what I'd do next
- [ ] Run instructions name every dependency and a fresh clone starts on the first command
- [ ] The cut list names each omission with a one-line reason
- [ ] One test covers the correctness-critical logic; trivial coverage was skipped on purpose
- [ ] No dead code remains from any abandoned approach
- [ ] The formatter and linter ran clean and logic is split by responsibility, not one big file
- [ ] I can explain every line I shipped in a live debrief

## Why the discipline matters more in a thin talent market

A clean, runnable submission with a decision-led README matters everywhere, but it matters most in niche stacks where the shortlist is short. In a thin market, one sloppy submission is a larger share of a recruiter's whole pool, so runnability and README discipline move you further.

The scale is real. In Refolk's index of professional profiles, 613 US "Software Engineer" profiles list Rust as a skill, against 54,977 that list Python. That makes the US Rust pool roughly 90 times smaller than the US Python pool. Narrow it by geography and it thins further: 89 Germany Rust profiles, about one-seventh the US Rust count.

| Segment | Profiles | Ratio |
|---|---|---|
| Rust SWE, United States | 613 | baseline |
| Rust SWE, Germany | 89 | 0.15x US |
| Python SWE, United States | 54,977 | 90x US Rust |

When the qualified pool is in the hundreds, not the tens of thousands, a reviewer remembers the submission that ran on first clone and stated its tradeoffs in two lines. The same discipline that gets you past the nine-minute pass is what makes you findable and shortlist-able in the first place, which is where a tool like [Refolk](/candidates) fits: it writes your resume from your own history and scores how well you fit a posting before you invest the hours in its take-home.

Recruiters looking to fill thin stacks are already searching the public graph for exactly the artifact this guide produces.

Ask me this: `Frontend engineers who have completed a public React take-home challenge and documented their scope tradeoffs.` - [run the search](https://www.refolk.ai/start?q=Frontend%20engineers%20who%20have%20completed%20a%20public%20React%20take-home%20challenge%20and%20documented%20their%20scope%20tradeoffs.).

*Returns candidates whose public work already shows the scoping judgment reviewers grade a take-home on.*

## Keeping this repeatable across a search

The version of this you want is not one heroic take-home but a repeatable routine you can run on the fifth one as calmly as the first. Save your README skeleton as a file you copy into every new prompt, so the structure is never a blank page under time pressure. Keep a personal note of the time log from each take-home you do, because your own 2x under-estimate is data: after three or four, you will know how long "a three-hour prompt" really takes you, and you can budget the split with confidence.

Re-check two things per prompt, because they are the parts that genuinely vary. First, the stated budget and calendar window, since ranges differ by role level and company, and the low end of your band is your working target. Second, the submission method, because a git host, a ZIP link, and a PR-based platform each want a slightly different final step. Everything else, the half-build split, the cut list, the decision-led README, the fresh-clone check, stays fixed. That fixedness is the point. The candidates who advance are not the ones who build the most; they are the ones who scope, document, and ship on budget, every time.

## Frequently asked questions

### How long should a take-home coding assignment actually take?

Respect the stated budget, typically 2 to 6 hours, with early-stage screens often 2 to 4 hours and senior roles 4 to 8. The trap is that authors under-estimate by about 2x, so spending the full stated time often already matches their real expectation. A FAANG manager put the ceiling plainly: six hours on a four-hour prompt is fine, forty hours is obvious. Time-log yourself and stop near the stated number.

### What do I actually put in a take-home README?

Open with what you built and what you would do next, because that is the one thing a reviewer is guaranteed to read. Then list your assumptions, exact run instructions with named dependencies, and your cut list with a one-line reason for each omission. rankid budgets 30 of 180 minutes to the README precisely because it is opened first and written last. The test is whether a stranger finds your key decision in under two minutes.

### Should I finish a feature or skip it and explain why?

Skip it and explain why. A sentence like 'I skipped pagination because the dataset is small' beats a half-finished pagination implementation, because a reviewer grades a decision in seconds but must debug a half-feature. Naming the cut demonstrates scoping, which is most of what senior roles are. A half-built feature demonstrates the opposite and leaves dead code that reads as noise.

### What is the single most common way take-homes fail?

Scope-blindness, usually as gold-plating. Reviewers compare your submission against the stated budget, so a polished build that clearly took three times as long signals someone who cannot scope work. The intent is good, candidates want to show craftsmanship, but extra features without alignment to the brief add complexity for no return. Keep any surplus effort in the written summary, not in features nobody asked for.

### How do I make sure my submission runs when the reviewer opens it?

Clone the repository fresh into a new directory and run the exact command in your README before you submit. Reviewers spend only a few minutes trying to start your code, and if it needs manual setup or fails to boot, it gets tossed. 'Works on my machine' is a false positive because your machine holds state a clean checkout does not. Test from zero, every time.

### Does my framework choice matter for a take-home?

Far less than most candidates think, and reaching for an unfamiliar framework to look current usually backfires. It produces code that looks unpracticed because it is, and reviewers can tell. The round rewards fluency, not novelty. Reviewers weight code organization and the README more heavily than framework choice, so build in the stack you know and spend the saved attention on scope and documentation.

---

*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-prompt-to-submission*