# The Submittable Take-Home Standard, Graded in Rejection Order *You can grade your completed take-home pass or fail on each dimension a reviewer checks, in rejection order, and fix every failing item before you send it.* - Canonical URL: https://www.refolk.ai/candidates/guides/submittable-take-home-standard - Pillar: Interviewing - Format: Standard - Published: 2026-09-22 - Last reviewed: 2026-09-22 - Reading time: 14 min 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. #### How a take-home narrows before the code is read | Stage | Figure | Note | | --- | --- | --- | | Submitted | 100% | everything sent | | Correct format | passes rule gate | wrong container auto-tossed | | Runs on a fresh clone | passes five-minute test | non-starters tossed | | Requirements met | passes coverage | missing must-have flagged | | Quality read | reached last | code quality, tests, communication graded | *Each gate eliminates submissions more cheaply than the next, so format and run failures never reach the quality read.* > **Rule:** Grade in rejection order, not in code order > > Fix format and runnability before you polish anything else. A dimension that eliminates the submission outranks every dimension a reviewer only reaches later. ## 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. | Dimension | What it grades | What it looks like when it fails | |---|---|---| | Correctness | The solution does what the brief asked | A required output is wrong or a special case is unhandled | | Code quality | Readable, maintainable structure | Reviewer spots smells before opening a checklist | | Tests | Coverage where correctness is at risk | The risky path is untested and the gap is unstated | | Scope | Deliberate choices about what to build | A half-finished feature instead of a named omission | | Communication | The README as instructions and as evidence | Sections exist but were never run in order | 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. | Company | Stated time | Source | |---|---|---| | CodeSubmit (recommended) | 2-4 hours | CodeSubmit challenge guide | | CodeSubmit (max any challenge) | 6 hours | CodeSubmit challenge guide | | Atlassian | 8 hours | CodeSubmit challenge guide | | Basecamp | 3-5 hours | CodeSubmit challenge guide | 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. **92% - completion rate CodeSubmit reports for its take-home challenges** Finishing is common; passing the format and run gates that come first is where submissions are lost. ## 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. **Submission README skeleton** ``` # One line: what I built and which brief this answers. ## Setup and install Prerequisites (with pinned versions): - - Install: ## Run Ready state: ## Usage and examples ## Technologies used ## Design decisions ## Requirements met - [x] -> - [ ] -> see Scope and trade-offs ## Scope and trade-offs - Decision: Cost: Revisit when: ``` *Replace each placeholder with real values; run every command from a fresh clone before you trust 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. > **Tip:** Write the README so the reviewer never has to guess > > Every bolded requirement in the brief should have a matching README section. If the brief bolds a word, treat it as a required heading in your submission note. ## 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. #### Grade your take-home before you submit 1. **Reconcile the brief** - Re-read the prompt and write down every deliverable, deadline, submission channel, branch or format rule, and allowed-dependency rule. Done means a written checklist of every explicit must, produced before you touch code. 2. **Grade requirement coverage** - Map each must-have to the exact file or function that satisfies it. Done means every required feature is ticked or explicitly listed as out of scope. 3. **Write the README** - Cover what you built, setup and install with pinned versions, a one-command run, usage examples, technologies used, design decisions, and requirements met. Done means every bolded requirement in the brief has a matching README section. 4. **Price the scope decisions** - For each deliberate omission, state the decision, its cost, and the condition that would make you revisit it. Done means no half-finished features remain and every gap is named. 5. **Run the fresh clone** - In a disposable environment carrying no local state, clone the repo and follow only the README to the ready state. On any failure, fix the doc or setup, discard, and restart. Done means one uninterrupted run reaches the ready state. 6. **Test the risky path** - Add tests where correctness is genuinely at risk and state explicitly what you left untested and why. Done means the risky path is covered and the omission is documented. 7. **Match the delivery format** - Package exactly as the brief asks - named zip, private repo, PDF versus pasted text. Done means the container matches the brief verbatim, with no credentials bundled. 8. **Run the final pass/fail grade** - Grade each dimension - format, runs, requirements, tests, communication, scope - pass or fail, and fix every failing item. Done means no dimension is left at fail. 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. #### The fresh-clone loop 1. **Clone clean** - create a disposable directory with no config or credentials 2. **Follow README only** - run only the documented steps to the ready state 3. **Hit a gap** - record the missing step or bad assumption 4. **Fix the doc** - repair the README or setup, not your local machine 5. **Discard and restart** - throw the environment away and clone fresh again 6. **Uninterrupted run** - one clean pass to ready state is your pass *Discarding the environment after each fix makes the README, not your memory, the thing under test.* > **Watch out:** Never claim a command is reproducible until you have run it from a fresh environment > > A README section that exists but was never executed in order is untested prose. Do not tick the run gate on the strength of prose alone. ## 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. **Priced trade-off entry** ``` Decision: I did not implement . Cost: . Revisit when: . ``` *One block per deliberate omission; every entry needs both a cost and a revisit condition.* 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. | Failure mode | The false positive | The check that catches it | |---|---|---| | Runs on your machine, not theirs | Local run passes on cached state or global installs | Fresh clone in a disposable directory with no config | | README is untested prose | Sections exist but commands were never run in order | Do not tick the run gate until run from a fresh clone | | One must-have missing | Complex bonus work masks a skipped simple requirement | Line-by-line map of every prompt must to code | | Half-finished feature | Dead code reads as incompleteness, not judgement | Remove dead code; convert to a named scope decision | | Trade-off stated as preference | "I chose X because it is cleaner", no cost named | Every decision carries a cost and a revisit condition | | Wrong delivery format | Correct code in the wrong container | Match the brief verbatim before anything else | | Credentials bundled or assumed | It runs for you because your keys are present | Separate public setup from private provisioning | | Non-code case graded as an essay | A polished narrative that never answers the scenario | Map each brief sub-question to a labelled section | 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. > **Watch out:** The wrong container tosses correct code > > Deliver the project exactly as asked - the specific folder setup, private link, or a zip with the exact name. A format error is enforced at the top of the funnel, before an engineer ever opens the code. ## 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. ```stat 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. ## Frequently asked questions ### Is my take-home good enough to submit? It is submittable when it passes every gate in order: the delivery format matches the brief verbatim, a fresh clone runs to the documented ready state from the README alone, every must-have requirement maps to code or a stated omission, the risky path is tested, and each scope decision is priced with a cost and a revisit condition. If any of those fails, it is not ready, no matter how strong the code is. ### What do reviewers look for in a take-home first? Format and runnability, in that order, before they read any code. Reviewers spend only a few minutes trying to start your project, so a submission in the wrong container or one that needs manual setup gets tossed before the work is judged. Only after it runs do they reach correctness, code quality, tests, scope, and communication. ### What does a take-home README have to contain? Five recurring sections: setup and install with pinned software versions, usage examples, technologies used, design decisions, and requirements met, plus a scope and trade-offs note. Write out every step to run the project from a fresh clone, including installation commands and how to start the server, and test those steps yourself. A reviewer should reach a running state following only the README. ### How are take-home coding challenges graded? Against named dimensions, often a written rubric. One platform grades its exercise against over thirty predetermined criteria for clean, readable, performant, maintainable code. The common five are correctness, code quality, tests, scope, and communication, applied after the format and run gates clear. Reviewers read for what you built, what you deliberately skipped, and whether you said so. ### Should I finish every feature or explain what I skipped? Explain what you skipped. A passing submission implements the requirements; a strong one implements the core well, names what it left out, and says why. A stated omission with a priced cost reads as judgement, while a half-finished feature or dead code reads as incompleteness. A smaller, honest submission delivered on time beats a larger gold-plated one. ### How do I test my take-home the way a reviewer will? Run a fresh-clone check. Clone the repo into a disposable directory that carries no config, credentials, or global installs, and follow only the README to the ready state. When a step fails, fix the doc or setup, discard the environment, and start again. The final uninterrupted run is direct evidence the README, not your memory, is sufficient. --- *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/submittable-take-home-standard*