Key takeaways
A take-home assignment is a test of judgment under a budget, and candidates lose it by treating it as a test of thoroughness. Reviewers are reading for what you chose to build, what you deliberately skipped, and whether you said so. The winning move is a smaller submission with a clear README explaining the tradeoffs, delivered on time. Gold-plating reads as poor prioritization, and it's the single most common way strong candidates fail this round.
What is a take-home assignment testing?
The take-home tests how you work when nobody's watching and the requirements are incomplete. That's the closest simulation of the actual job in the entire loop, which is why companies keep using it despite candidates disliking it.
Reviewers are answering three questions when they open your submission. Did this person understand what was being asked. Did they make sensible calls about what to include given the stated time budget. And would reviewing their pull requests be pleasant or exhausting. Notice that none of those are "did they finish everything."
The time budget is the part candidates most often misread. A prompt that says "spend about four hours" is not an invitation to spend twelve. Reviewers compare submissions against the stated budget, so a submission that clearly took three times as long doesn't read as dedication. It signals someone who can't scope work, and scoping is most of what senior roles are.
How long should you spend on a take-home?
Spend the stated budget, then stop and write the README. If the prompt gives no budget, ask for one, because that question alone signals the right instinct.
Timing matters on the calendar too. Interview loops are shorter than the polishing instinct assumes, with Ashby's 2026 Recruiting Operations Benchmarks reporting medians of 14.4 days for business roles and 17.9 days for technical roles, and a take-home usually falls somewhere in the middle of that. Sitting on it for a week to polish burns a meaningful share of the loop and gives the impression you're juggling other processes, even when the work is good. Returning it in two or three days with an honest scope note is a stronger signal than returning it in eight with more features.
Four-Leaf covers the surrounding timeline in how long it takes to hear back after applying.
What do take-home reviewers score?
Three dimensions, and they hold across engineering, data, design, and marketing versions of this round. Run each against the three things every take-home implicitly asks: build the thing, decide what "done" means, and explain yourself.
Did you scope it deliberately? A passing submission implements the requirements. A strong submission implements the core requirements well, names what it left out, and says why. "I skipped pagination because the dataset is small and the tradeoff wasn't worth the four hours" is a better sentence than a half-finished pagination implementation.
Is it readable? A passing submission works. A strong submission is organized so a reviewer can find the interesting decision in under two minutes. That means a README that opens with what you built and what you'd do next, sensible file structure, and no dead code left behind from an abandoned approach.
Did you test the thing that matters? A passing submission has some tests or none. A strong submission tests the part where correctness is genuinely at risk and says explicitly that the rest was left untested on purpose. Blanket coverage on trivial code is box-ticking. One well-chosen test on the tricky logic is judgment.
How does the take-home differ by role?
The three dimensions hold. What counts as the core deliverable changes completely.
Software engineering. Usually a small service or feature with a stated time budget. Reviewers weight code organization and the README more heavily than most candidates expect, and they weight framework choice far less. Use what you know well.
Data analyst. Usually a dataset and a vague question. The deliverable is the finding, not the notebook. Lead with the answer and the caveat that qualifies it, then show the work. Analysts lose this round by producing twelve charts and no conclusion.
Data scientist. Usually a modeling task where the honest answer involves uncertainty. Reviewers look for whether you validated properly, whether you noticed leakage, and whether you were candid about what the model can't do. A modest model with a clear-eyed evaluation beats a better score with no error analysis.
Design. Usually a product problem with a short brief. The process artifacts carry as much weight as the final screens, because the round exists to check whether the visuals came from reasoning. Include the version you rejected.
Growth and marketing. Usually a plan or a teardown. Specificity is the axis. Named channels, a budget split, and a measurable hypothesis beat a well-formatted strategy document with no numbers in it.
What is overrated
Feature completeness. Reviewers are not scoring a checklist, and the marginal feature almost never changes the decision. The README does.
Novel technology choices are the other trap. Reaching for an unfamiliar framework to look current usually produces code that looks unpracticed, because it is. Reviewers can tell, and the round rewards fluency rather than novelty.
There's also a fairness question worth naming honestly. Take-homes ask for unpaid hours and they disadvantage candidates with caregiving responsibilities or a current job that runs long. It's reasonable to ask a recruiter whether a live pairing session can substitute. Some companies will say yes, and the ones that say no have told you something useful about how they operate.
A five-step playbook for a take-home
- Read the prompt twice and write down the stated budget. If there isn't one, email and ask before you start.
- Decide what you are not building before you write anything. Write that list down, because it becomes your README.
- Build the core path end to end before adding anything. A working narrow version beats a broad broken one every time.
- Write the README last and lead with tradeoffs. What you built, what you skipped, what you'd do next with another day, and how to run it.
- Rehearse the walkthrough out loud. Nearly every take-home is followed by a review conversation where you defend your choices, and that conversation is scored separately. A voice mock interview is a reasonable way to practice narrating a technical decision under follow-up questions.
Where this is heading
Take-homes are being restructured rather than retired, and assistants are the reason. CodeSignal reported in February 2026 that cheating and fraud attempts on proctored assessments more than doubled, from 16% in 2024 to 35% in 2025, with entry-level rates nearly tripling from 15% to 40%. In a 2025 interviewing.io survey of 67 interviewers, 52 of them at FAANG companies, 81% suspected candidates of using AI and about a third had caught someone. Nobody seriously believes an unsupervised take-home is now a test of unaided ability.
The response has been to move the weight onto the conversation that follows. Companies increasingly treat the submission as material for a live review rather than as the evaluation itself, which means the round is quietly becoming an oral exam about code you wrote days earlier. That's a good outcome for candidates who actually made the decisions in their submission, and a difficult one for everyone else. Four-Leaf's take on where that line sits is in real preparation versus cheating, and the rounds that surround the take-home in how an onsite interview loop actually works.