# The Submitted Take-Home Standard, Graded Before You Send It

*You will be able to grade your completed take-home against a reviewer's pass/fail rubric and clear every failing item before you hit submit.*

- Canonical URL: https://www.refolk.ai/candidates/guides/submitted-take-home-standard
- Pillar: Interviewing
- Format: Standard
- Published: 2026-08-18
- Last reviewed: 2026-08-18
- Reading time: 15 min

You finished the take-home. The link is ready to send. This guide is the pre-submit QA pass: a definition of done you can grade your own artifact against, the same pass/fail criteria a reviewer effectively applies in the first minutes, and the checklist to clear every failing item before you hit submit. It is written for the candidate who has already built the thing and now needs to know whether it survives contact with a busy reviewer.

Other guides carry a take-home from prompt to a finished deliverable. This one starts where that ends. It does not tell you whether the employer's ask was fair. It tells you what fails, so you can catch the defects that auto-reject before anyone else sees them.

## Why the first minute is a gate, not a grade

A reviewer runs your submission before reading it, and if it does not start, most of the grading never happens. The single highest-leverage check is whether your project clones and runs on a machine that is not yours.

The BigPanda Engineering reviewer guide reports that a great deal of submissions fail on execution alone, and that the majority of those failures come from packages missing from the dependencies list - the `package.json` or `requirements.txt` that should have named them. The reviewer's first act is to run it and compare the output against the requirements. If it throws on install, the review effectively stops there, and nothing you wrote about your elegant architecture gets read.

This reframes what "done" means. Done is not "I believe it works." Done is "it started from a fresh checkout using only the steps in my README." Those are different claims, and the gap between them is where most rejections live.

**33% - Share of 51 top-tier companies with disclosed processes that include a take-home or async assignment**

The take-home is a common enough gate that a reusable pre-submit standard pays for itself across a job search.

There is a complication worth naming early. Reviewers do not all behave the same way. One published account says they usually do not even run the code and judge on readability and structure instead. Another rejects on the first thrown error. You cannot know which reviewer you drew, so the only safe target is a submission that both runs cleanly and reads clearly. Optimizing for one camp and ignoring the other leaves half your risk uncovered.

## What auto-rejects: the reviewer's implicit rubric

The rubric a reviewer applies is short, ordered, and mostly binary. Each criterion below states what it proves and what it looks like when it lies to you.

| Criterion | What it proves | What it looks like when it lies |
|---|---|---|
| Clones and runs from clean checkout | The manifest is complete and setup is reproducible | Runs on your machine because of global installs, breaks on the reviewer's |
| Every requirement demonstrably works | You delivered the asked-for scope | You remember building it, but never re-verified it line by line |
| Test suite passes | The implementation is not broken | Tests green locally, red on the reviewer's runner due to committed cruft |
| Tree is clean | Care and readability | Debug logs, commented code, and node_modules read as carelessness |
| Scope matches the prompt | You can justify every decision | Impressive extras that invite "why did you build this?" |

The failure that recurs most across reviewer accounts is code that will not run because of a missing dependency. Close behind is missed requirements: to a surprising degree, most submissions do not satisfy all of the requirements, and reviewers find this by grading output against the prompt rather than trusting the candidate's summary.

> **Rule:** The clean-clone rule
>
> Your submission is not done until it starts on a fresh clone using only the README steps. If you have not deleted your local modules and run it clean, you have not verified the one thing the reviewer checks first.

Two more defects auto-reject without ever being about your code quality. Committed dependency folders break continuous integration: one submission failed CI because committed `node_modules` held system-specific compiled binaries that did not work on a Linux runner. And copying is caught - reviewers have flagged candidates who submitted someone else's repository. Neither is a judgment call. Both are hard fails.

## The reviewer pool you are actually writing for

The person grading your take-home is usually a working engineer or engineering manager fitting the review between their own deadlines, and the market you are in shapes how time-pressed they are likely to be. In Refolk's index of professional profiles, the reviewer pool for this title is heavily concentrated in one market.

| Market | Engineering Managers | Share of pair | Top employers |
|---|---|---|---|
| United States | 42,116 | 80.4% | Meta, Google, Datadog |
| United Kingdom | 10,244 | 19.6% | Meta, Deliveroo, Zopa |
| US : UK ratio | 4.1x | - | Meta appears in both |

The counts and employers come from Refolk's index; the shares and the ratio are derived from those counts. The practical read: a US candidate is statistically far more likely to be reviewed by one of a large pool of busy managers, which rewards submissions built for fast verification. The faster a reviewer can confirm your work runs and meets requirements, the less your submission depends on their patience.

**4.1x - How much larger the US Engineering Manager pool is than the UK's in Refolk's index**

42,116 in the US versus 10,244 in the UK - a busier, more time-pressed reviewer pool on average.

There is a second timing fact that changes how you write your documentation. It can take up to two or three weeks between submission and the review meeting. Whatever you were thinking when you built it will be gone by then, and so will the reviewer's memory of your prompt. Your README and design notes are what you will both be reading at the discussion. Undocumented cleverness becomes a liability precisely when you have to defend it out loud.

> Undocumented cleverness becomes a liability at the exact moment you have to defend it out loud.

## The pre-submit procedure, step by step

Run this sequence in order. It mirrors the reviewer's own path - run it, check it against requirements, read it - so you catch each defect at the stage the reviewer would.

#### Grade your take-home before you send it

1. **Re-read the prompt and list every requirement** - Read the instructions carefully and write out a checklist of every deliverable and condition. Each item should map to something a reviewer can verify. Note any assumptions you made.
2. **Run it from a fresh clone** - Delete local caches and modules, clone into a clean directory, and start the app using only your README steps. Missing env vars or locally installed databases surface here instead of at the reviewer.
3. **Confirm requirement-by-requirement parity** - Run the app and compare its output to each checklist item, not to memory. Every listed requirement must demonstrably work; most submissions miss at least one.
4. **Run the tests and make them green** - Run the full suite yourself and confirm it passes, then state coverage in the README. A PR with failing tests reads as a broken implementation.
5. **Clean the tree** - Remove committed dependency folders, commented-out code, and debug logs, and confirm a .gitignore is present. The diff should contain only code that maps to a requirement.
6. **Cut scope creep** - Remove or clearly mark any feature the prompt did not ask for, moving genuine ideas to a short future-work note. Every file should map to a stated requirement.
7. **Write or verify the README against a fixed section list** - Fill in clone, install, and run commands, versions, env vars and secrets, design decisions, and how to test. A stranger should be able to run it without contacting you.
8. **Reserve the final hour for packaging, not building** - Spend the last hour polishing docs and packaging rather than adding features, and submit through the code host the company uses. Consider a Docker container so environment differences do not block the reviewer.

#### The reviewer's path, which your QA pass should mirror

1. **Clone and run** - The reviewer starts your project from a clean checkout; missing dependencies fail here
2. **Check requirements** - They compare output against the prompt, line by line
3. **Read the code** - They judge structure, naming, and whether extras are justified
4. **Read the README** - They look for setup, design decisions, and how to test
5. **Discuss weeks later** - They defend or question your documented decisions with you

*Grade at each stage the reviewer will grade, in the order they hit it.*

Two of these steps deserve heavier weight because they are where most self-graders fool themselves. Step two exposes the "it runs on my machine" illusion: globally installed packages make a broken dependency list look complete. Step three exposes the "I met all the requirements" illusion: you built each feature, so you assume it still works, but you never re-ran the checklist against live output.

## The README section standard

The README is the part of your submission that a reviewer reads no matter which camp they fall into, and it is the artifact you will defend weeks later. Four independent guides converge on the same required sections, so treat their union as the standard.

| Section | freeCodeCamp | eliya-b | Myachenkov | thisdot |
|---|---|---|---|---|
| Clone + install + run commands | yes | yes | yes | yes |
| Software / dependency versions | yes | - | yes | - |
| Env vars / secrets | - | yes | yes | - |
| Design / architecture decisions | - | - | yes | yes |
| Tests / how to test | yes | - | - | yes |

The one section every guide agrees on is the run instructions. Make no assumptions: write out all steps to run the app locally and test them yourself, including cloning, install commands, and starting the server, with the versions of software you used. Then delete caches and modules, start from a fresh copy, and confirm the README provides everything needed - for both client and server - to bring it up.

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

```
# Project Name

One-line description of what this does.

## Requirements met
- [Requirement 1 from the prompt] - see [file/route]
- [Requirement 2 from the prompt] - see [file/route]

## Prerequisites
- Language + version (e.g. Node 20.x)
- Any services (e.g. Postgres 15)

## Setup and run
1. git clone <repo>
2. <install command>
3. Copy .env.example to .env and set: <list every var>
4. <command to start the server>
5. App runs at http://localhost:<port>

## Running the tests
- <command> - full suite should pass; coverage: <number>%

## Design decisions
- Why I structured it this way
- Tradeoffs I made and what I would change with more time

## Out of scope / future work
- Things I deliberately did not build
```

*Delete any section the prompt genuinely makes irrelevant; keep the run steps no matter what.*

If you tailor a resume or cover letter for the same application, [Refolk](/candidates) drafts those from your own history, which frees your remaining hours for the packaging pass this guide describes rather than rewriting boilerplate.

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

Most rejected take-homes are not bad work. They are good work that failed a check the candidate never ran. Each failure mode below names the trap, the false positive that hides it, and how to check locally.

### It runs on my machine

The false positive: globally installed packages make a broken dependency list look complete, so the app starts for you while the manifest is missing entries. Check by running from a fresh clone or a fresh container, never from your working directory. Deploying somewhere clean is another way to prove nothing is missing.

### Green tests locally, red on the reviewer's runner

The false positive: your tests pass because your environment carries state the reviewer's does not - often committed `node_modules` with system-specific binaries, or hard-coded local paths. Check via CI or a clean clone on a different operating system if you can. This is the failure that turns committed convenience artifacts into silent auto-fails.

### All requirements met, by memory

The false positive: you built every feature, so you assume every feature still works. Reviewers find that most submissions miss at least one requirement. Check by grading line by line against the checklist you extracted in step one, running the actual output, not by re-reading your own code.

### Impressive extras as a positive signal

The false positive: unrequested features feel like they show range. They read as over-engineering and invite "why did you build this?" questions you cannot justify. A reviewer documented a submission that used a database with a secured token and many unneeded configs, and the time spent there meant important features did not work well. Check that every file maps to a stated requirement.

> **Watch out:** The two-camp trap
>
> Do not optimize only for the reviewer who runs your code, and do not optimize only for the one who reads it. One account says reviewers usually do not even run it; another rejects on the first error. A working-but-messy repo fails the first reviewer, and a clean-but-broken repo fails the second.

### README that assumes context

The false positive: the setup steps are obvious to you because you wrote the project. They are not obvious to a stranger. Check by having someone else - or yourself on a clean box - follow the README verbatim without asking you a single question.

### Leftover debug code and messy commits

The false positive: the app works, so the state of the tree feels cosmetic. Commented-out code, debug logs, and a chaotic commit history read as carelessness to a reviewer who judges on clarity. Check the diff and the commit history before you submit, the way a code reviewer would.

#### Runs versus reads, and what each quadrant costs you

Horizontal axis runs from Does not run cleanly to Runs on clean clone. Vertical axis runs from Reads badly to Reads clearly.

| Quadrant | What it means |
| --- | --- |
| Broken and messy | Auto-reject on both axes; start the QA pass from step two |
| Runs but messy | Fails the reviewer who judges on clarity; clean the tree and commits |
| Clean-looking but broken | Fails the reviewer who runs it; fix the manifest and clean-clone it |
| Runs and reads clearly | The only safe submission; ship it |

*You need the top-right; every other quadrant fails at least one reviewer camp.*

## Scope discipline, and why extras cost you twice

Keep only what the prompt asked for, and move genuine ideas to a future-work note. Sources agree that unrequested features hurt more than they help, and the mechanism is simple: time spent on extras is time not spent making the required features solid.

If an idea accomplishes or improves on the requirements, it is likely worth keeping. If it is tangentially related or just cool, it is scope creep. It is more impressive to keep scope narrow and finish everything you set out to do than to sprawl and leave requirements half-working. Over-engineering also sends the wrong message at the discussion stage, because a decision with no clear reason behind it is a negative when the reviewer asks you to defend it.

That is why extras carry negative expected value. They fail you once by diverting build time from requirements, and again by generating questions you cannot answer weeks later. The future-work note lets you show the idea without paying either cost.

## The time envelope for the final pass

Reserve the last hour for polishing and packaging, not for building. No source validates an exact split, so treat any ratio as a heuristic rather than a rule, but the direction is consistent across named guides.

| Source | Build window | Polish guidance |
|---|---|---|
| askcruit | 4-8 hrs over 3-5 days | Last 1 hr on docs, not features |
| algocademy | Milestone-based | Extra time to polish, not new functionality |
| thisdot | 3-5 days | Avoid over-engineering |

With extra time in hand, the higher-value move is polishing existing code and the README, or improving quality, rather than implementing more functionality. Then submit through the code hosting service the company uses so the reviewer can simply clone it, and consider putting the project in a Docker container so environment differences never block them.

Before you send the link, run this final gate.

#### Pre-submit gate

- [ ] The project starts from a fresh clone using only the README steps
- [ ] Every requirement on my extracted checklist demonstrably works against live output
- [ ] The full test suite passes and coverage is stated in the README
- [ ] No node_modules or other dependency folders are committed, and a .gitignore is present
- [ ] No debug logs, commented-out code, or leftover experiments remain in the diff
- [ ] Every file maps to a requirement; extras are removed or noted as future work
- [ ] The README covers clone, install, run, versions, env vars, design decisions, and how to test
- [ ] A stranger, or I on a clean box, followed the README with no questions
- [ ] The commit history is clean enough to read
- [ ] It is submitted through the code host the company uses

## Keeping this standard current

Adopt this as team or personal policy, then re-check the two assumptions that can drift. First, the reviewer's behavior: if a company tells you upfront that they run submissions in CI, weight the clean-clone and tests checks even harder; if they emphasize a discussion round, weight the design notes. Second, the time envelope: caps have trended longer over time, with one account describing a move from a one-hour limit to four-plus hours, so read the current prompt's stated window rather than assuming.

To pressure-test your own README before you submit, it helps to see how experienced reviewers structure setup instructions. Find people who do this work in the open and study their repos.

Ask me this: `Engineers who maintain open-source repos with exemplary README setup instructions.` - [run the search](https://www.refolk.ai/start?q=Engineers%20who%20maintain%20open-source%20repos%20with%20exemplary%20README%20setup%20instructions.).

*Returns maintainers whose run instructions you can model your own README against.*

The standard itself does not go stale. Code that clones, runs, passes its tests, meets its requirements, and reads clearly will clear a reviewer's first minute regardless of the year or the stack. Re-run the gate on every submission, and the defects that auto-reject stop reaching the people deciding whether to advance you.

## Frequently asked questions

### Is my take home assignment good enough to submit?

It is ready when it clones and runs on a clean machine using only the README, every listed requirement demonstrably works, the test suite is green, and the tree holds no committed dependency folders, debug logs, or unrequested features. Grade it against those criteria line by line rather than trusting your memory of what you built. If a stranger can run it without contacting you, you have cleared the reviewer's first-minute gate, which is the bar most submissions fail.

### What do reviewers actually look for in a take home assignment?

Reviewers first check that the code runs, then that it satisfies every stated requirement, then that it is readable and scoped to the prompt. The BigPanda reviewer guide reports the top killer is code that will not run, usually from a dependency missing from the manifest. Some reviewers never run the code and judge on clarity alone, so a working repo that reads badly can still fail. Write for both camps.

### What are the most common reasons a take home assignment gets rejected?

The recurring auto-reject causes are code that will not run on a clean checkout, missing dependencies not listed in package.json or requirements.txt, failing tests, committed node_modules that break CI, missed requirements, and obvious copying of another repository. Reviewers have caught candidates who copied someone else's repo. Over-engineering with unrequested features also hurts, because it diverts time from requirements and invites questions you cannot justify.

### How much time should I spend polishing versus building the take home?

Named guides suggest reserving the final hour for documentation and packaging rather than new features, within a build window that most take-homes design for at four to eight hours over three to five days. Treat any exact split as a heuristic, not an established rule, since no source validates a percentage. The higher-value use of leftover time is polishing existing code and the README, not adding functionality that expands scope.

### Should I include extra features to stand out on a take home?

No. Extra features carry negative expected value because they divert time from the requirements and read as over-engineering. One reviewer documented unrequested database and token configuration that caused core features to break. Employers will ask why you built each thing, and decisions with no clear reason count against you. Keep scope narrow, finish everything the prompt asked for, and move genuine ideas to a short future-work note.

---

*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/submitted-take-home-standard*