The Take-Home Submission Standard, Seven Gates Graded Before You Send

A take-home is ready to send when it passes seven gates, each graded pass or fail. I wrote this for candidates who have finished a take-home (a code repo, an analysis notebook, a PM doc, or a marketing or design deck) and need to know whether it will get a debrief or the canned rejection. Each failed gate points to one named fix with a time cost, so you can decide whether to fix it before sending or name it in the cover message.

What does "ready to send" mean for a take-home?

A take-home is ready to send only when it passes all seven gates: traceable to the brief, scoped to the brief, runs or opens on the first try, framed by a doc that states assumptions and tradeoffs, time declared, delivered clean, and defensible in the debrief. If one gate fails, the submission isn't ready.

The gates are binary for a reason. Medium's published engineering interview rubric grades each category "on a five point scale: Strong No, No, Mixed, Yes, and Strong Yes," and it treats "Mixed to be more No than Yes." This next part is my interpretation, not measured data: if you half-meet a criterion, expect it to be graded as a fail. A standard that accepts "mostly done" lets you send work that comes back Mixed.

The gates work for any take-home type because they test how the deliverable relates to the brief and to the reviewer, not the stack or the styling. That doesn't mean polish is free. I haven't found an employer that publicly says it ignores stack or styling, so don't assume it. Reviewers do say where their attention goes. One design source puts it this way: "Senior reviewers care more about how you reason than how polished the artifact is." Indeed's UX lead looks for "the ability to scope tasks, prioritize, and think critically."

The gates are layered. A reviewer only reaches a layer if every layer above it held.

Who reviews a take-home, and what do they open first?

Your reviewer is most likely a hands-on lead such as an engineering manager, not a recruiter, and they open the README or framing document first. Write for someone technical who has no context and limited time.

Refolk's index of professional profiles shows the population a reviewer is likely drawn from. Treat these counts as population sizes. They aren't data on who gets assigned to review.

The title data is clean. In a sample of 25 US profiles titled Engineering Manager, 22 carry that exact title. UK sampled employers include Meta, Deliveroo and Zopa Bank, and sampled US Technical Recruiter employers include Snowflake, Google and Blue Origin.

The first thing that reviewer opens is the README or its equivalent. CodeSubmit documents its review order: "reviewers read the README, manifests, and top-modified files that explain how the submission works." One practitioner calls the README "the first thing opened and the last thing most candidates write." For a deck, the equivalent is the summary slide. For a notebook, it's the first markdown cell.

The evidence on reviewer time is thin. One cost model counts 25 minutes for the reviewer's first-pass scoring and 12 minutes of written debrief, but that figure is modelled, not measured. I haven't found a measured reviewer-minutes figure with a stated method. If you want a local check, ask the recruiter how long the review stage usually takes. Either way, design your submission for a reader who stops at the first point of friction.

The seven gates, criterion by criterion

Each gate below has a pass condition, what it proves, how it lies (the false positive that makes it look passed when it isn't), and the one fix with its time cost. The time costs come from the procedure further down.

Gate 1: Traceable to the brief

• Passes when: every requirement in the brief maps to a specific file, slide, or cell, one to one.
• Proves: you read the brief as a spec. Data engineering reviewers are said to ask directly: "did you build what was asked, or what you found interesting?"
• Lies when: extras are listed as "bonus" while a core requirement is missing. A long feature list can hide a gap.
• Fix and cost: build the requirement map, about 15 minutes. If a core requirement is missing, building it takes priority over everything else in this guide.

Gate 2: Scoped to the brief, with no scope creep

• Passes when: anything you added beyond the brief is labelled as extra and costs the reviewer nothing to skip.
• Proves: you can scope and prioritise, which is the skill Indeed's UX lead names first.
• Lies when: the extra work is impressive but changes how the reviewer has to engage. In one failure case, a task built around three CSV files was delivered as a system that needed "reading configuration for twenty minutes."
• Fix and cost: label or cut the extras during the 15-minute mapping pass. If the brief banned something, such as an external library, using it is an instant fail. One candidate-side writer says you "will fail it and not proceed to the next step." Remove it.

Gate 3: Runs or opens on the first try

• Passes when: a fresh clone in a clean environment, or the file opened on another machine, works by following only the README.
• Proves: the reviewer can reach your work without debugging your setup.
• Lies when: it works on your machine because of a globally installed dependency, a cached credential, or a locally installed font that the README never mentions.
• Fix and cost: do a clean-room run, 15 to 30 minutes. Practitioners ask you to check that it "compiles and runs" and to "list prerequisites and dependencies."

Gate 4: A framing doc that names assumptions and tradeoffs

• Passes when: a reviewer with no context can follow the summary and run steps, and each assumption names the ambiguity in the brief that it resolves.
• Proves: judgement. Writing as a candidate, Geshan rated the "Decisions and Tradeoffs" section as "one of the most important."
• Lies when: the assumptions block lists only assumptions that don't matter ("I assumed the input is UTF-8") and skips the ambiguity that shaped the design.
• Fix and cost: write the framing doc, about 30 minutes, which is the share one practitioner puts on the README. Use the skeleton below for any take-home type. I haven't seen employer data on which section decides outcomes, so include all of them.

# [Project name]

## Summary
One paragraph: what the brief asked, what this delivers, and where to look first.

## How to run or open
Prerequisites: [runtime and version, tools, accounts, fonts]
1. [command or action]
2. [command or action]
Expected result: [what the reviewer should see]

## Brief to artifact map
- Requirement 1: [file, slide, or cell]
- Requirement 2: [file, slide, or cell]
- Extras, not requested: [list, safe to skip]

## Assumptions
- The brief says "[ambiguous phrase]". I assumed [X] because [Y].

## Decisions and tradeoffs
- Chose [A] over [B] because [reason]. What [A] gives up: [cost].

## Left out on purpose
- [item]: about [time] to add. I prioritised [other item] instead.

## Next steps with more time
- [step]

## Time spent
Budget: [stated hours]. Actual: [hours]. [One line if over budget.]

Gate 5: Time kept and declared

• Passes when: actual hours appear against the stated budget, and any overrun has a one-line explanation.
• Proves: you managed the constraint. The Holloway guide warns that without declared hours, "you might be comparing candidates who spent 40 hours with those who spent only 2."
• Lies when: you declare six hours on a three-hour brief with no explanation, which reads as a scoping failure. Leaving the time undeclared also fails, because it invites the 40-versus-2 comparison.
• Fix and cost: add one line, about 2 minutes. CodeSubmit suggests employers "ask them afterward to disclose how long they spent on it," so volunteering the number costs you nothing.

Gate 6: Delivered clean

• Passes when: the work arrived on time through the right channel and branch, in an accepted file type, and with no identifiers if grading is blind.
• Proves: nothing about your skill, and that's the danger. Platform plumbing can reject or delay correct work before any rubric is applied.
• Lies when: you got a "sent" confirmation but the upload was rejected or the push landed after the deadline.
• Fix and cost: delivery check, about 10 minutes, plus 10 minutes to strip identifiers where grading is blind. Details are in the platform section below.

Gate 7: Defensible in the debrief

• Passes when: for every component, you can say why you chose it, what the alternative was, and what you would do with another hour.
• Proves: the work is yours and you understand it. Kyle Evans argues there "should" be "an interview where you walk through the work, ask questions, and allow the candidate to discuss," and Cabify ends with "a zoom interview to talk about your project's solution."
• Lies when: the code or analysis looks strong but includes parts you can't explain, including AI-generated parts. CodeSubmit's CodePair lets an interviewer "ask why you chose a boundary, how you would extend the solution, or what you would fix with another hour."
• Fix and cost: rehearse the debrief, 30 to 60 minutes. You can do this after sending, but only if everything you sent is something you can defend.

Every element in the artifact becomes a debrief question, so build only what you can defend in depth.

The debrief rarely stays on the take-home alone. Interviewers also probe the resume line that got you into the loop. If your resume came from Refolk, it was written from your own history, so each line describes work you can explain as deeply as the take-home.

How long should you spend on a take-home assignment?

Spend no more than the stated budget, and declare your actual hours either way. Completion falls steeply as budgets grow, so a long overrun mostly shows that you could afford the time.

Two sources report completion by stated budget. Easyapply says its figures come from "50,000+ interview processes," but its method is unverified, so read the numbers as direction, not precision.

Clarity-hire's explanation is the one worth remembering: long tasks measure "availability and desperation as much as skill." Other figures point the same way. interviewing.io puts overall take-home completion at about 62%, and Dropbox found that 20% of candidates did not complete them before it dropped take-homes.

Published budgets vary. CodeSubmit reports that "Atlassian has an 8-hour time limit and Basecamp estimates that their assignments take 3-5 hours." Design exercises are described as running "four to eight hours, done alone." When the brief states no budget, ask for one before you start. If you can't, pick a budget, put it in the framing doc, and grade yourself against it.

Don't solve an overrun by asking for an extension at the last minute. Indeed's hiring guidance lists scrambling, extension requests and rushed work as possible "concerns about how well they manage their time." Send what you have inside the budget, declare the hours, and name the gap.

How to submit a take-home assignment on each platform

Submit through exactly the channel the brief names, in an accepted file type, before the deadline, then open what you sent to confirm it arrived. Each platform has its own way to fail, and none of them involve quality.

What each row means in practice:

• Greenhouse: through the default upload link, candidates "cannot upload executable files such as .exe, .js, .bat, and .py." If your deliverable is code, use the channel the brief gives for code, such as a repo link. If the brief only gives an upload link, ask the recruiter which format they want. I haven't found a published rule on upload size limits, so ask about that too if your files are large.
• CodeSubmit: the platform "expects a commit and push to the provided Git repository," and an invite "can use a due date, active time limit, or both." An employer reviewing CodeSubmit wrote: "Sometimes candidates fail to push the code in time and we have to manually follow-up." Don't make them chase you.
• CoderPad Screen: a submission "expects saved files followed by the Submit button." If you save but don't press Submit, nothing was submitted.
• Ad Hoc: grades blind, gives every submission a random number, and asks that "candidates remove any identifying information from their submission."

Blind grading matters more than it looks. When a Greenhouse Job Admin ticks "Hide candidate name and details from grader," graders get "a trimmed-down email that does not include the candidate's information." Greenhouse's study of about 384,000 applicants measured the effect.

That margin cuts both ways. If an artifact identifies you on a blind-graded stage, you lose the protection the employer switched on. Greenhouse lists anonymised take-home grading under a paid subscription tier, and the tier name has changed before, so you can't tell from the outside whether a Greenhouse employer uses it. If the brief mentions blind or anonymous grading, strip identifiers. If it doesn't, ask.

The pre-send procedure, in order

Run these seven steps in order after the build is finished. In total they take roughly two to three hours, most of it in the clean-room run, the framing doc, and the debrief rehearsal. The steps produce the evidence for the seven gates.

Sources disagree on when the framing doc gets written. One says to spend the last hour on the README, and another says to write the summary document last. Both put it after the build, and neither publishes evidence. I put it third, after the clean-room run, because the run usually exposes setup steps the README has to include.

The mapping in Step 1 is the same skill as tailoring a resume to a posting, which is to read the text as a list of requirements and show where each one is met. Refolk tailors your resume to every posting automatically, so that time goes to the take-home instead.

How take-home submissions fail: failure modes and false positives

Most rejections of finished work come down to a gate the candidate believed had passed. Each failure mode below has a false positive that makes it look passed, and a check that catches it.

1. Building what interested you instead of what was asked. The three-CSV task delivered as a system that needs twenty minutes of configuration reading is the typical case. False positive: a long list of bonus features while one core requirement is missing. Check: map requirements to locations one to one. A requirement without a location is a fail, however much else is there.
2. "Works on my machine." A dependency installed globally, never listed, makes the README look complete. False positive: it ran fine every time you tried it, always on your own setup. Check: a fresh clone in a clean container, or the deck opened on someone else's machine.
3. The work never arrived. A .py file uploaded through the Greenhouse link is rejected. A CodeSubmit push after the deadline means someone has to chase it by hand. Saved CoderPad files without the Submit press were never submitted. False positive: you clicked send. Check: open the submission link or remote branch afterwards and confirm your final version is there.
4. Time misdeclared or undeclared. Six hours declared on a three-hour brief reads as a scoping failure. Leaving the hours out invites the reviewer to compare you with someone who spent 40. False positive: you think the extra effort shows commitment. Check: hours are stated, and any overrun is explained in one line.
5. Anonymity broken. A name in package.json, the git author, file metadata, or a slide footer breaks blind grading, and Greenhouse's 6.5 to 10% pass-through effect suggests that can cost you. False positive: the visible pages are clean. Check: search the files and inspect the metadata.
6. An assumptions block that assumes nothing important. It lists safe, irrelevant assumptions and skips the ambiguity that drove the design. False positive: the section exists and has bullets. Check: every assumption quotes or names the ambiguity in the brief that it resolves.
7. Work you can't defend. Code or analysis you can't explain, including AI-generated parts, falls apart under follow-up questions. The interviewing.io data shows why this matters: 38% of candidates who finished a take-home did so because it "would be discussed at the onsite." The debrief is where the outcome gets decided. False positive: the artifact looks strong. Check: for each component, say out loud why you chose it, what the alternative was, and what another hour would buy.
8. Mixed quality across gates. If you partly meet several criteria, you can get a Mixed grade everywhere, and Medium's rubric counts Mixed as more No than Yes. This is my reading of the rubric, not outcome data. False positive: nothing is obviously broken. Check: grade each gate strictly pass or fail, never "mostly."

Base rates are why this matters. Before Dropbox dropped take-homes, its pass-through rate was "close to 10%." Most finished submissions don't advance, so a submission that fails on plumbing or framing gives away a scarce chance before anyone grades the content.

Fix before sending, or note it in the cover message?

Fix every hard fail before sending. Name a gap in the cover message only when it's a gap you can explain and fixing it would cost hours you don't have. Two things decide which case you're in: how severe the failure is, and how long the fix takes.

Hard fails are the ones that stop the reviewer from grading: a missing core requirement (Gate 1), a banned dependency (Gate 2), a submission that won't run or open (Gate 3), and a broken delivery or anonymity (Gate 6). Gaps you can note are missing extras, an unfinished nice-to-have, or a known limitation that your tradeoffs section already covers. Gates 4 and 5 take 32 minutes together, so there's never a reason to send without them.

When you do name a gap, the cover message is where the reviewer sees it first. Keep the message short. It should point to the framing doc, not repeat it.

Subject: [Role] take-home submission, [your name or candidate ID]

Hi [name],

My submission for the [role] take-home is [pushed to the main branch of the repo you shared / attached as a PDF / at this link]. I opened it from a clean copy before sending.

Please start with [the README / slide 2 / the first notebook cell]. It maps each requirement in the brief to where it lives.

Time: the brief suggested [X] hours and I spent [Y]. [If over: one line on what took longer and why.]

One known gap: [item]. I left it out to prioritise [other item]. The tradeoffs section covers how I would add it.

Happy to walk through any of it in the debrief.

[Name]

Pre-send checklist and keeping this standard current

Go through this checklist immediately before you press send. Every item is a statement you can verify as true or false, and the submission is ready only when all of them are true.

The facts in this standard that change are platform mechanics: which file types an upload link blocks, which subscription tier includes blind grading, and how a timer or due date is enforced. Don't rely on a remembered value. Before each submission, read the platform constraints in the invite or brief. If they're missing, ask the recruiter three questions: what format and channel to use, whether grading is blind, and what the time budget is. The seven gates themselves don't change, because they're about how your deliverable relates to the brief and the reader.

When your submissions keep failing the same gate, the problem is your process, not the individual take-home. Keep a one-line record of which gate failed on each submission and fix that step of the procedure first.