Most take-home challenges are decided in the first five minutes of review, and the code is rarely what gets read first. The reviewer opens the README. Then they run the tests. Only if both of those go well do they start reading your actual solution with any patience.
I've read a lot of take-homes. The ones that fail usually fail for a boring reason: the engineer treated the assignment like a coding puzzle when it was really a small piece of work for a stranger who has 20 minutes and a stack of other submissions.
Key Takeaways
- Reviewers read the README and run the tests before they read your code. Optimize for that order.
- Finishing a smaller scope well beats finishing everything badly. Write down what you cut and why.
- Say which AI tools you used and how. Hiding AI use is the bigger risk.
- Time-box hard. A take-home that took 14 hours when the brief said 3 tells the reviewer something too.
What the reviewer actually does with your submission
Here is the rough order most technical reviewers follow, whether they admit it or not:
| Step | What they check | What kills you |
|---|---|---|
| 1. Open the README | Can I run this in under 2 minutes? | No setup steps, or steps that don't work |
| 2. Run it | Does it start? Do the tests pass? | Missing env vars, a broken install, zero tests |
| 3. Skim the structure | Is this organized the way a teammate would organize it? | One 600-line file, dead code, commented-out experiments |
| 4. Read the core logic | Is the hard part handled correctly? | Edge cases ignored without a word |
| 5. Read your notes | Does this person think about tradeoffs? | No notes at all |
Notice that correctness only shows up at step 4. If step 1 or 2 fails, a lot of reviewers stop there, or they keep going already annoyed. That's not fair, but it's how a busy engineer reads 12 submissions on a Thursday.
So the README is part of the solution. Put the run command at the top. List the Node or Python version. If there's a database, give a docker compose file or use SQLite. Then test the whole thing from a fresh clone before you submit, because "works on my machine" is the most common failure I see.
Scope control is the real test
Most take-homes are written to be slightly too big on purpose. The reviewer wants to see what you do when you can't finish everything.
The strong move: pick the core path, make it solid, and write a short "What I'd do next" section. Something like:
Implemented: CSV import, validation, the three report endpoints, tests for the parsing edge cases.
Skipped: pagination (the sample data is 200 rows), auth (out of scope per the brief), retry logic on the external rate API.
With another 2 hours: I'd add pagination and move the rate lookup behind a cache.
That paragraph does more for you than an extra feature. It shows judgment, and judgment is the thing a US team can't easily teach a remote hire.
Tests matter more than coverage numbers. Five tests that hit the tricky cases (empty input, bad dates, duplicate rows, a timezone boundary) beat 40 tests that check the happy path. If you only have time for a few, test the part the brief made hard on purpose.
AI tools: disclose, don't hide
Two years ago the question was whether you could use Copilot or Claude on a take-home. Now most teams assume you did. What they want to know is whether you understand what you shipped.
Add a short section: which tools you used, for what, and what you changed by hand. "I used Claude to scaffold the Express routes and write the first draft of the tests. I rewrote the date parsing because the generated version broke on DST changes." That sentence makes you look better than pretending you typed every line.
What hurts you is code you can't explain. Many companies follow the take-home with a live walkthrough, and in our process a human team interview comes later too. If a generated function has a subtle bug and you can't say why it's there, the take-home now counts against you. We test candidates both with and without AI tools for exactly this reason. We wrote more about how that shift changed interviews in rethinking technical interviews for the AI era.
One more thing, and it's a security thing: only clone and run repos from a company you have verified. Fake "coding tests" that install malware are a documented attack on developers: Microsoft describes victims being told to clone and run a package from GitHub, GitLab, or Bitbucket. We cover how to spot them in how to spot a fake remote developer job offer.
A Concrete Version
This is a composite, based on patterns we see often, not one real person.
Two backend engineers get the same brief: build a small API that imports transaction CSVs and returns monthly totals per category. Suggested time: 3 hours.
Engineer A spends 11 hours. The API has auth, pagination, a React dashboard nobody asked for, and a Kubernetes manifest. No README beyond "npm start." The install fails because a `.env` value is missing. There are two tests, both for the happy path.
Engineer B spends 3.5 hours. FastAPI, SQLite, a Makefile with `make run` and `make test`. Nine tests, four of them on malformed CSV rows and one on a transaction dated 23:30 on the last day of the month in a UTC-5 timezone. The README has a "Decisions" section with four bullets, including "amounts stored as integer cents to avoid float rounding," and a note that Copilot wrote the first pass of the Pydantic models.
B moves forward. A usually doesn't, even though A clearly wrote more code. The reviewer's note on A would read something like "can't tell what they'd do with a real ticket."
The Honest Counterpoint
This advice assumes the company reads take-homes carefully. Some don't. Some send a 10-hour assignment with no review rubric and ghost you after. Scope control won't save you there.
So before you start, ask two questions: how long do you expect this to take, and how will it be reviewed? If the answer to the first is "a weekend" and the role is one of forty you are applying to, it's fine to decline. A take-home is unpaid work. Doing three of them a week is a fast way to burn out without learning anything.
And if you are a strong live coder who freezes on open-ended assignments, say so. Some teams will offer a pairing session instead. We compare the two formats in take-home vs live coding interviews.
Frequently Asked Questions
Should I go over the suggested time to make it better?
A little, fine. Double or triple, no. Say how long you spent in the README. An honest "about 4 hours" reads better than a polished submission that clearly took a weekend.
Is it OK to use a framework or boilerplate?
Yes, unless the brief says otherwise. Using the tools a real team would use is a good sign. Mention it so the reviewer knows which code is yours.
What if I don't understand part of the brief?
Ask. A short, specific question to the recruiter or hiring manager is a positive signal. If nobody answers, write your assumption down in the README and move on.
The Bottom Line
Treat the take-home like the first ticket you'd ship to a new team: runs on the first try, tested where it matters, scoped honestly, with a short note explaining your choices and your AI use. That combination is rarer than you'd think, and it gets you to the next round.
If you want to put it to use, our roles for Python backend engineers and fullstack TypeScript engineers start with a coding assessment, and you can see every open role here.
Roberto Espinoza is CEO of Ruzora, which places senior LATAM engineers with US startups. Browse open roles.
