The fastest way to fail a take-home is to treat it like a personal project with no deadline. Reviewers are not scoring effort. They are scoring whether your code is correct, readable, and something they would accept in a pull request. The candidates who stand out do three things: they scope their time up front, they make the repo trivial to evaluate, and they spend their marginal hour on tests and a README instead of gold-plating features nobody asked for. Below is how we tell people to approach take-homes, based on watching engineers over-prepare and under-deliver in the same session.
Set a time budget before you write a line
Most take-homes come with a stated estimate ("this should take about 3 to 4 hours"). Believe it, then plan to the low end. The prompt is usually calibrated so a strong engineer finishes the core in that window, and the reviewer will read your submission through that lens. If you hand in something that clearly took 15 hours, you have not impressed anyone; you have signaled that you cannot ship inside a constraint, which is the actual job.
Concretely:
- Read the entire prompt twice and write down the explicit requirements as a checklist before coding.
- Reserve the last 20 percent of your budget for the README, cleanup, and a final test run. This is the part people skip, and it is the part reviewers see first.
- If you run out of time, stop and document what you would do next. A finished 80 percent with honest notes beats a broken 110 percent.
The trap is open-ended prompts with no time cap. Those are the dangerous ones, because "as good as you can make it" has no floor. Impose your own cap. Four to six hours is a reasonable ceiling for most take-homes, and anything past that has diminishing returns for the signal it sends.
Understand what reviewers actually grade
A senior engineer skimming your submission is answering a small set of questions in the first few minutes. Roughly in this order:
- Does it run? Clone, follow the README, execute. If setup fails here, everything below is discounted.
- Is it correct on the obvious cases and the annoying edge cases? Empty input, single element, off-by-one boundaries.
- Can I read it? Clear names, small functions, no dead code, consistent style.
- Did they test it? Presence and quality of tests is the single biggest differentiator we see between "maybe" and "yes."
- Did they make sensible tradeoffs and say so? Not the "perfect" architecture, the appropriate one for the scope.
Notice what is not on that list: clever one-liners, a custom framework, or handling requirements that were never stated. Reviewers reward code that is boring and correct. Save the cleverness for the parts of the design that genuinely need it.
Make the repo say "yes" in five minutes
Assume the person grading your submission has 20 other candidates in the queue and 10 minutes each. Optimize ruthlessly for their time.
Write the README first, then keep it updated. It should answer, in order: what this is, how to run it, how to run the tests, what you chose to build and why, what you left out, and what you would do with more time. Three paragraphs and a code block is plenty. A good "what I'd do next" section is where you show senior judgment without spending senior hours.
## Run
npm install && npm start
## Test
npm test
## Notes
- Chose an in-memory store to keep setup zero-config; a real system would use Postgres.
- Skipped auth (out of scope per the prompt).
- With more time: add rate limiting and pagination on /items.
Use small, meaningful commits. A single "final solution" commit tells the reviewer nothing about how you think. A dozen commits with messages like "add validation for empty input" or "handle duplicate keys" lets them watch your reasoning unfold. Some teams read your git history closely; give them a good story.
Write tests that document intent. You do not need 100 percent coverage. You need tests that prove the core logic works and that you thought about failure modes. A handful of well-named tests covering the happy path plus two or three edge cases beats a wall of shallow assertions.
Where to spend your marginal hour, and where not to
Once the core works, engineers waste time in predictable places. Here is our blunt allocation guide.
| Spend time on | Skip or timebox |
|---|---|
| Tests for edge cases | UI polish beyond what's asked |
| A clear README with tradeoffs | Custom build tooling or configs |
| Input validation and error handling | Premature abstraction and interfaces |
| Consistent formatting (run a linter) | Features not in the prompt |
| One clean pass to delete dead code | Micro-optimizing code that isn't hot |
The most common self-inflicted wound is building for a scale the prompt never mentioned. If the task is "parse this file and return a summary," you do not need a plugin architecture. Adding one reads as poor judgment, not ambition. State the tradeoff in the README instead: "This runs in memory; for files larger than RAM I'd stream and aggregate incrementally." You get full credit for the insight at zero cost.
The second wound is inconsistent style. Run a formatter and a linter before you submit. It takes two minutes and removes an entire category of easy criticism.
When the take-home is a tightly scoped algorithm problem
Not every take-home is a mini web app. Some firms, especially quant and trading shops like Susquehanna, hand you a self-contained algorithmic problem and judge it on correctness, complexity, and clean implementation. Here the rules shift slightly: there is no "product" to over-build, so the entire signal is in your solution quality, your tests, and your ability to explain the approach.
The problems in this bucket look exactly like the matrix and array work we see most from SIG: Rotate Image, where you rotate an n x n matrix 90 degrees clockwise in place; Spiral Matrix, returning all elements in spiral order; Rotating the Box, simulating stones falling under gravity; and Text Justification, a fiddly greedy string problem where the edge cases (single-word lines, the last line, distributing spaces) are the whole test. Others in the same style include Design Memory Allocator, Restore the Array From Adjacent Pairs, Number of Black Blocks, and Minimum Absolute Difference Between Elements With Constraint.
For this flavor, standing out means:
- Nail the in-place or space constraint if it is stated. Rotate Image is explicitly in-place; solving it with an extra matrix is a partial answer, not a full one.
- Enumerate edge cases in comments or tests. For Text Justification, that means the last line being left-justified and lines with one word padded to
maxWidth. Showing you found these is most of the grade. - State the time and space complexity in the README or a comment, and say whether it is optimal.
- Keep the solution readable. A correct but unreadable spiral traversal scores worse than a slightly slower one that a reviewer can follow.
If you want to build fluency on this exact category before a real take-home lands, drill the underlying patterns rather than memorizing solutions. Our matrix interview questions set covers rotation and spiral traversal, and you can run timed reps with feedback on DevInterview practice. For firm-specific patterns, the company breakdowns show which problem types actually recur.
A quick note on AI
Using an AI assistant on a take-home is now normal, and many teams assume you did. What still gets you rejected is submitting code you cannot explain. Reviewers frequently follow the take-home with a live walkthrough where they ask you to modify or extend your own solution. If you generated it and never understood it, that conversation ends the process. Use AI to move faster, then read every line, write your own tests, and make sure you can defend each decision out loud.
FAQ
How long should a take-home coding assignment actually take?
Aim for the low end of the stated estimate, and cap open-ended prompts yourself at roughly four to six hours. Reviewers calibrate the prompt for a strong engineer finishing in that window, and a submission that obviously took far longer signals poor time management, not diligence.
Do I need 100 percent test coverage?
No. You need tests that prove the core logic is correct and that you considered edge cases. A focused suite covering the happy path plus two or three failure modes sends a stronger signal than exhaustive but shallow assertions, and it fits your time budget.
Should I mention things I did not have time to build?
Yes, always. A short "what I'd do next" section in the README is where you demonstrate senior judgment for free. It shows you understood the full problem and made deliberate tradeoffs rather than missing requirements.
Is it okay to use ChatGPT or Copilot on a take-home?
Generally yes, and many teams assume you will. The hard rule is that you must be able to explain and extend every line, because a follow-up walkthrough is common. Treat AI as a speed multiplier, not a substitute for understanding.
What matters more, features or code quality?
Code quality and correctness, by a wide margin. A smaller scope done cleanly, tested, and documented beats a broader feature set that is messy or buggy. Reviewers reward code they would accept in a pull request, not the longest submission.