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

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.

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.

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.

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.

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.

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.

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.

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.

# 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

If you tailor a resume or cover letter for the same application, Refolk 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.

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.

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.

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.

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.

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.