Spend exactly the hours the brief states, then stop. The stated budget is a scoring instruction, not an estimate, and almost every brief describes more work than it names: a four-hour full stack task built line for line usually lands nearer seven or eight. So the thing being tested is not throughput, it is scoping. Cut the brief down to what fits, ship something that runs on a clean machine, and write a README that names everything you left out.
Stated time versus real time, by format
These are planning heuristics drawn from the shape of common briefs, not measured data. Use them to size your cut list before you write code, not to argue with a recruiter about the estimate.
| Format | Brief says | Building every line takes | The cut that lands you on the number |
|---|---|---|---|
| One or two algorithm problems, single file | 60 to 90 min | 1.5 to 2 hours, mostly edge cases | Ship the clean O(n log n) with a comment naming the linear idea. Do not implement both. |
| Backend API with persistence and one hard requirement | 3 to 4 hours | 6 to 9 hours once setup, auth and Docker creep in | SQLite or an in-process store, no auth unless the brief names it, no container. |
| Full stack app, API plus UI | 4 to 6 hours | 8 to 14 hours, most of it front end polish | One unstyled table with the hard behaviour actually working beats three pretty screens. |
| Front end build from a design file | 3 to 5 hours | 6 to 10 hours chasing pixels and breakpoints | Match spacing and interactive states at one viewport width. List the others as not done. |
| Data or ML notebook | 4 to 6 hours | 8 to 12 hours of tuning and chart polish | One baseline, one improvement, one honest error analysis. No hyperparameter sweep. |
| Extend a repo they send you | 2 to 3 hours | 3 to 5 hours, because reading is unbudgeted | Give the first 45 minutes to reading, and say so in the README. |
| Timed platform assignment with a countdown | 90 to 180 min, enforced | The same, the clock decides for you | Read every question in the first five minutes and order them by points per minute. |
The pattern is identical across the rows. The overrun is almost never in the interesting requirement, it is in the scaffolding around it: environment setup, a login screen nobody asked for, styling, and tests on the parts that were never at risk.
The three questions to email before you write a line
Send one message within an hour of receiving the brief, with three questions and your defaults already stated. The defaults are the trick: they let a busy recruiter reply in one word, or not reply at all, while you start on schedule with your reasoning on record.
Thanks for sending this over. I will have it back by Thursday evening. Three quick things so I put the time where you want it.
1. What does the reviewer look at first? I would rather spend the hours on the parts you actually grade.
2. Is the four hours a budget you want me to stop at, or an estimate? And is Thursday a hard deadline?
3. If everything does not fit, would you prefer a smaller scope that works properly, or the full scope roughly done?If it is easier not to answer, my defaults are: stop at four hours, prioritise a smaller working scope, and document what I left out.
How to read what comes back:
- A rubric, or "we run it and read the tests", is the best case. Build to that sentence, and put your tests where they said they look.
- "Spend as long as you like" is not generosity. It means submissions are compared against unbounded effort. Cap it anyway, and say what your cap was.
- "Polish matters" inverts your plan. Cut a requirement rather than cutting finish, and name the cut requirement in the README.
- No reply within a day costs you nothing. You wrote the defaults down, so you are executing an agreed plan rather than improvising.
Nobody has been rejected for asking those three. Candidates are regularly rejected for building the wrong half of the brief beautifully.
A four-hour plan that actually stops at four hours
Start a visible timer. Commit at the end of every block, with a message naming the block. That gives the reviewer a legible history and gives you a rollback point when a block overruns.
0:00 to 0:20 · Scope, and write the cut list first
Read the brief twice and split every requirement into must, should and cut. That cut list is the deliverable of this block, and it becomes a README section later. Then name the one hard requirement: the concurrency case, the idempotent write, the pagination, the retry. That is what is being graded.
0:20 to 0:40 · Something that runs, from empty
Repo, one start command, seed data with real rows, and a stub README with the run instructions written before the code exists. Commit. If a crisis takes you out at hour two, this is still a submittable artefact.
0:40 to 2:00 · The hard requirement, end to end
Not the data layer, not the model classes. The thin vertical slice that demonstrates the graded behaviour. Hard-code anything that is not the point, and commit the moment the behaviour works, before you tidy it.
2:00 to 3:00 · Second requirement, plus the two tests that matter
Two tests on the hard requirement outrank twenty on CRUD getters. Write the failure case rather than the happy path: the duplicate submit, the concurrent edit, the empty page of results.
3:00 · Feature freeze, no exceptions
The rule that makes the rest of the plan real. At three hours you write no new functionality, even if you are twenty minutes from finishing something, because that twenty-minute estimate is the one that has been wrong all afternoon. A half-built feature fails on a clean clone. The same feature as one README line costs nothing and reads as judgement.
3:00 to 4:00 · README, clean clone, submit
Forty minutes of writing, twenty of verification. Clone into a fresh directory and follow your own instructions literally, with none of your shell history and none of your environment variables. Delete dead code and commented-out experiments. Send it.
When a block overruns, take the time from the next block, never from the last one. The README hour is the highest-value hour in the assignment, and it is the first thing most candidates sacrifice.
The README template
Six sections. The first gets you reviewed at all, and the middle four are where a scoped submission beats an over-built one.
- Run it. Exact commands in order, the versions you used, and what you should see when it works. Something like
npm ci && npm run seed && npm start, then "eight orders at localhost:3000/orders". Seed data is not optional, an empty list view cannot be assessed. - Assumptions. Every ambiguity you resolved alone. "The brief did not say whether cancelled orders count towards the limit. I assumed they do not." That line converts a possible bug report into a design decision.
- Trade-offs. A fixed shape: what you chose, what you rejected, why, and what it costs. "Optimistic concurrency with a version column rather than a row lock. The edit endpoint is the only writer, and I would rather return a 409 than hold a transaction open across a user's thinking time. Cost: the client must handle 409 and refetch."
- What is untested. Name the riskiest untested path plainly. "No test on the webhook retry path. It is the most fragile code in here and it is what I would write first." The reviewer already knows what you skipped, so saying it first turns a gap into calibration.
- With another day. Your cut list from block one, reordered by value instead of effort. Three or four lines, specific enough to be a plan rather than a wish.
- Time spent. The real number, and where it went. If you overran, say by how much and on what.
These sections also set the agenda for the follow-up call. Interviewers reliably open on the trade-offs you volunteered, so you get questioned about the decisions you already have answers for.
Where this breaks down, and where we are the wrong tool
Time-boxing does not repair a bad brief. Plenty of four-hour assignments ask for authentication, deployment, a test suite and documentation, which is a scoping failure by the company rather than by you. You can overspend, submit a scoped version with the cut list attached, or decline. The scoped version is the only one that also tells you something, because a team that rejects a clearly reasoned four-hour submission has shown you how it estimates internally.
Reviewers are also not uniform. There are companies where the candidate who spent twelve hours does win, and against those, a disciplined four hours loses. You cannot tell which from the brief, which is why the second question in that email is worth asking.
Then the tooling limit. Code Copilot from OfferPilot AI is built for live rounds, where you capture a problem on screen and get intuition, a dry run and complexity back in about a second. It is not built for ghostwriting a submission, and using it that way is a poor trade whatever the policy says, because a take-home is defended line by line on a call. Some specifics before assuming it fits your situation:
- Windows 10 and 11 only. No macOS, Linux, mobile or browser extension build.
- Capture exclusion covers screen sharing and recording, nothing else. The overlay is excluded from capture at the operating system level, so it does not appear in Zoom, Teams, Meet, OBS or screenshots, while staying visible on your own monitor. It does nothing about a webcam, a lockdown browser, eye tracking, a proctor sitting beside you, or a second-device camera.
- The brief sets the rules. Some companies permit AI assistance with disclosure, others prohibit it outright. Read it, and ask if it is ambiguous.
The one-line version
Scope to the stated hours, freeze features at 75 per cent of the budget, and spend the last quarter writing down what you did not do.
The place preparation pays most is the round after the submission, when someone reads your diff with you and asks why. Rehearse that: clone your own repo, run it from your own README, and answer the three decisions you would attack if you were reviewing a stranger. The company Q&A generator builds a question bank for a named company and role, which covers the non-code half of that call, and the question banks cover the usual follow-ups. The free tier is 5 minutes a day with no card, and paid plans start at $39 a month.