A take-home brief suggests about six hours of work but allows five days - how do you scope it?

## Two numbers, and only one of them is a budget A take-home brief typically carries two figures: an effort estimate (about four to eight hours is the common range) and a submission window (commonly three to five days). They mean different things. The effort estimate is what the work is graded against - it tells you the size of solution the reviewer expects and the depth they will look for. The window exists so a candidate with a full-time job, a family and an inconvenient time zone can find those hours somewhere. Treating the window as the budget is the single most common scoping mistake, and reviewers see the result constantly. ## Spending a six-hour budget A workable split for a six-hour brief, drawn from a remote-first scale-up's data-engineering take-home - ingest messy event files, deduplicate, expose a daily aggregate: - **45 minutes** reading the brief twice, writing down the acceptance criteria in your own words, and sketching the data flow. Cheap, and it is where most misreads die. - **3 hours 5 minutes** building the core path end to end: files in, records deduplicated, aggregate out. Nothing decorative. - **65 minutes** on tests that cover the logic you would be embarrassed to get wrong. - **40 minutes** on the README - run instructions, scope, tradeoffs, gaps. - **15 minutes** buffer, which you will use. That is five hours and fifty minutes. If the core path is not working by the end of the third hour, that is information: cut a requirement rather than extending the day, and say in the README which one you cut and why. ## Depth beats breadth Given a brief with four requirements and six hours, a submission that implements two of them properly - with tests, error handling on the unhappy path and a clear README - beats one that gestures at all four. The reviewer is trying to answer whether you can be trusted with a piece of real work. One finished thing answers that. Four half-finished things answer a different, worse question. ## The overbuild trap The failure that costs the most is the enthusiastic one. A candidate reads a six-hour brief, treats the five-day window as licence, asks for an extension, and submits on day nine after roughly 31 hours - the brief's core path plus a dashboard, a container setup and a plugin layer nobody asked for. Three things go wrong at once. The reviewer cannot compare that submission against candidates who spent six hours, so it distorts the calibration the rubric depends on. The extra surface introduces bugs in code the rubric never asked about. And the scoping signal - the thing a senior role is actually being screened for - comes back negative: this person could not identify what mattered and stop. If you did overshoot, the honest move is a README line saying so, with the hours you spent and what you would cut. That converts a scoping failure into a demonstration of self-awareness, which is worth more than pretending. ## When the brief has no stated budget Some briefs give only a deadline. Ask the recruiter or hiring manager what effort they expect - a normal, low-risk question that also signals you scope work before starting. If no answer comes, set your own budget, state it in the README, and build to it. A submission that says up front that it represents about five hours of work gives the reviewer the frame they need to judge it fairly. ## Buying time correctly Asking for a longer window because of a genuine constraint - travel, an on-call week, another employer's deadline - is normal and usually granted. Asking for more time so you can build more is the overbuild in disguise. The distinction a reviewer draws is between when you can do the work and how much work you decided to do.