The Submittable Take-Home Standard, Graded in Rejection Order

You finished the take-home. The code works on your machine, the README exists, and the deadline is close. This guide answers one question: is it done enough to send? It gives you a pass/fail definition of done for the finished artifact, graded on each dimension a reviewer actually checks, in the order they check it, so you can fix every failing item before you submit. It is written so two reviewers would grade the same submission the same way.

Most take-home guides cover the request, the run, or the walkthrough from prompt to sent. This one grades the artifact itself, and it orders the grading by the gates that eliminate a submission before anyone reads the actual work.

What a reviewer rejects first, and why order matters

A reviewer applies criteria in cost order, not importance order. The cheapest checks to run come first, and they eliminate submissions before any code is read. This is the single fact that reshapes how you should self-grade: a brilliant solution that fails setup never earns the quality read.

One practitioner guide frames the early checks as sequential filters. The first is following simple rules: if you mess up the submission rules, it reads as an inability to follow basic office procedure, and it gets thrown out automatically. The second is the five-minute test: reviewers only spend a few minutes trying to run your code, and if it does not start or needs manual setup, it gets tossed. Expert reviewers at Geektastic confirm that code-quality issues surface only after the run gate, because clean code that works is easy to spot well before anyone reaches a line-by-line review checklist.

So the grading order is fixed by the reviewer's scarcest resource, which is attention. You should grade in the same order, because a failure at gate one makes every later dimension irrelevant.

The five dimensions a reviewer grades

A reviewer grades a take-home on five named dimensions: correctness, code quality, tests, scope, and communication. Those are the load-bearing criteria in most published reviewer accounts, and some roles add dependency choices, security, performance, accessibility, or framework fluency when relevant.

The grading is often written down. Slack grades its exercise against a rigorous set of over thirty predetermined criteria, looking for code that is clean, readable, performant, and maintainable. You will not see their rubric, but you should assume one exists and that each dimension is scored separately.

Two of these dimensions are easy to under-weight. Communication is a full dimension, which means a thin README loses points even when the code is perfect. And scope is graded as judgement, not volume, so what you deliberately skipped and whether you said so counts as much as what you built.

The README carries two of these dimensions at once. It is scored once as instructions - can a reviewer run the project from it - and once as evidence that you can communicate, because that is a graded dimension in its own right.

How long the reviewer thinks it should have taken

A reviewer reads your submission against an expected time box, and gold-plating past that box reads as poor judgement rather than diligence. Published time limits cluster between two and eight hours, and none of the major published challenges are meant to run longer than a workday.

CodeSubmit recommends a two-to-four-hour limit and states that none of its challenges take longer than six hours. Atlassian sets an eight-hour limit; Basecamp estimates three to five hours. The lesson is not that you must finish inside the stated window, but that a reviewer expects the shape of a submission that fits it. The winning move is a smaller submission with a clear README explaining the trade-offs, delivered on time.

Completion is not the hard part. CodeSubmit reports a 92% completion rate for its challenges, and a recruiter account reports that half of pre-qualified developers dropped out when handed a take-home at all. The people who submit are mostly people who finished. What separates them is whether the finished artifact passes the gates below.

The README a reviewer can actually run

The README must let a reviewer reach a running state following only the README, with no assumptions about your machine. This is the single artifact that carries two graded dimensions, so it is worth more of your time than one more feature.

FreeCodeCamp's reviewer guide is blunt about the standard: do not make any assumptions, write out all the steps to run the app locally, and test them yourself. That includes cloning the repo, running installation commands, starting a server, and stating the versions of the software you used. Microsoft's official README guidance adds the same shape from the platform side: link the required versions of prerequisite software, give install-via-package-manager commands such as npm install or pip install, and include the test-run commands. A named practitioner closes his checklist with a Docker or free-hosting deploy, run and test instructions, third-party tools used, and documented design choices.

The five recurring README sections are the spine. Build them in this order.

# <Project name>
One line: what I built and which brief this answers.

## Setup and install
Prerequisites (with pinned versions):
- <language> <version>
- <package manager> <version>
Install:
    <clone command>
    <install command, e.g. pip install -r requirements.txt>

## Run
    <one command that starts the app or builds the package>
Ready state: <what the reviewer should see when it works>

## Usage and examples
<one worked example input and its expected output>

## Technologies used
<languages, frameworks, third-party tools, and why each>

## Design decisions
<the key choices, findable in under two minutes>

## Requirements met
- [x] <must-have from brief> -> <file/function>
- [ ] <out of scope> -> see Scope and trade-offs

## Scope and trade-offs
- Decision: <what I did or skipped>
  Cost: <what it costs>
  Revisit when: <the condition that reverses it>

A four-leaf guide sets a useful communication bar: a strong submission lets a reviewer find the key decision in under two minutes. If your design rationale is buried, the reviewer scores communication down even though you did the thinking.

The self-grade procedure, run in the reviewer's order

Grade the finished artifact in eight passes, in the order below, and fix every failing item before you send. The order matters because it mirrors the gates: administrative and run checks come before deep code checks, so a failure early makes later work moot.

Sources disagree on how much rigour the fresh-clone pass needs. Some say a single clean-machine run is enough; a published fresh-clone loop requires repeated discard-and-restart until a run completes uninterrupted. Use the stricter version when setup is non-trivial, because that is exactly where a hidden step lives.

The fresh-clone check, which removes your memory from the loop

The fresh-clone check reproduces the reviewer's first pass by testing the README instead of your memory. You clone into a disposable environment that carries no config, credentials, or global installs, and you follow only the README to the ready state. When a step fails or assumes knowledge you did not document, you record the gap, fix the doc or setup, discard the environment, and start again. The final uninterrupted run is direct evidence that the README, not the operator, is sufficient.

This works because local state hides missing steps. A worked verification creates a fresh clone in a disposable directory such as /tmp/python-setup-check and does not stop until every step is verified from that clean start. Even automated pipelines miss what this catches: a Mastodon issue documents a case where CI passed but a clean clone broke, because an undocumented precompile step was required. Passing CI is not evidence of a reproducible README.

Pricing scope so incompleteness reads as judgement

A named omission with a stated cost reads as engineering judgement; a half-finished feature reads as incompleteness. The mechanism is simple: a decision whose cost is not stated reads as a preference, so pricing the trade-off converts an opinion into a defensible decision the reviewer is explicitly grading.

The model sentence is concrete: "I skipped pagination because the dataset is small and the trade-off was not worth the four hours" beats a half-built pagination implementation. Reviewers read for what you chose to build, what you deliberately skipped, and whether you said so. A practitioner repo formalises this into a trade-off entry that carries a cost line and a revisit-when line, verified by a grep count, precisely because a README that argues for its decisions but never prices them reads as taste rather than judgement.

Decision: I did not implement <feature>.
Cost: <what the reviewer loses because of this - be specific>.
Revisit when: <the concrete condition that would make me build it - data size, traffic, deadline>.

Before you submit, remove dead code from abandoned approaches. Dead code reads as an unfinished feature, not a decision. Convert every abandoned attempt into either a working path or a named scope decision.

A decision whose cost is not stated reads as a preference, and a reviewer grades preferences down.

How this goes wrong: eight false positives

Most rejected submissions passed on the candidate's own check and failed on the reviewer's, because the candidate's check had a false positive. Each failure mode below names the false positive - the thing that made you think it was fine - and the check that catches it.

The first two are the most common and the most expensive, because they fail the run gate, which is the second gate. Doing something complex does not excuse missing a simple requirement, so the requirement map matters even when your code is impressive. And the last row applies to non-code take-homes: for a marketing or analytics case, structure functions as the rubric. Map the description, goal, hypothesis, implementation, results with data, and findings each to a labelled section, so a reviewer can check that every part of the scenario was answered.

Who applies each gate, and what it means for your check

Format and rule compliance is enforced by non-engineers first, which is why delivery-format errors auto-reject before any code is read. In Refolk's index of professional profiles, US technical recruiters and talent-acquisition professionals with an interviewing skill outnumber hiring and engineering managers who carry a technical-recruiting skill by roughly 11 to 1 - 1,211 against 108. The top of the funnel is recruiters, not engineers.

number: 11.2x
label: US technical recruiters versus hiring/engineering managers in Refolk's index
note: The people who first check format and submission rules are usually not the people who read your code.