Take-Home Coding Assignments: What Reviewers Look For
How take-home assignments get reviewed: scope an MVP, write a README anyone can run, test the edges, document trade-offs, and prepare for the live round.
- coding assignment interview
- developer homework interview
- take home test tips
- interview project scope
Short answer: a software engineer take home assignment is judged on how you scope, document, test and ship without anyone watching. Build a small working version first, make it run with one command, test the edge cases in the brief, and write down your trade-offs and what you left out.
Reviewers are usually fitting your submission in between their own work, so the README and the shape of the repo create most of the first impression. Clever code buried in a repo that will not start does not get seen.
Take-homes are a different skill from live coding, where you are timed and explaining as you go. If your loop has a live round too, the practice problems and the voice AI interview on TechInView are built for that part.
What reviewers look at
| Signal | Weak | Strong |
|---|---|---|
| Scope | Every possible feature | Clear MVP plus an "if I had more time" list |
| README | No run steps | One command to run, assumptions, trade-offs |
| Tests | None, or flaky | Happy path and edge cases, fast to run locally |
| Code shape | A few huge files | Modules with obvious boundaries |
| Config | Hard-coded secrets | Environment config with a .env.example |
| Honesty | Claims of polish | Known limits and next steps |
Much of this overlaps with the problem-solving and code-quality dimensions in interview scoring rubrics, just reviewed after the fact instead of live.
Before you write code
- Restate the requirements in the README, split into must-have and optional.
- Time-box exploration, for example 90 minutes, before making choices that are hard to undo.
- Pick a boring stack unless the brief asks for something specific. Anything the reviewer has to install or learn counts against you.
- Define one success check, such as "the CLI finishes in under 2 seconds on the sample input."
Controlling scope when the brief is vague
- If you are truly blocked, send one short question ("Can I assume a single user?") and keep working while you wait.
- Get one path working end to end early. A thin working slice beats several half-built layers.
- Stub out stretch goals and say so in the README.
A minimal README
## What this does (one paragraph)
## How to run
## How to test
## Trade-offs and limits
## If I had 3 more hours
Tests that read well
- Name tests after behaviour ("rejects expired tokens"), not method names.
- Cover the boundary cases the brief mentions.
- If there is a UI, one reliable end-to-end test or a short screen recording is usually enough. Do not go further unless asked.
Common ways to lose points
- API keys committed anywhere in the git history
- Tests that depend on timers or the network and fail randomly
- Ports and environment variables nobody documented
- Heavy frameworks or dependency injection for a four-hour task
How this fits with the rest of the loop
Many companies pair a take-home with a live coding round, and often ask you to walk through your submission. The skills carry over:
- A clear README is the written version of thinking out loud.
- Knowing the cost of your own code matters in both; see the time complexity cheat sheet.
Once you have submitted, switch to live practice. The AI mock interview guide covers how to get reps if you are rusty at talking while coding.
FAQ
Should I add Docker?
Only if the brief mentions deployment or the team clearly uses it. Otherwise a README and a couple of scripts are fine.
Can I copy code from Stack Overflow or an AI assistant?
Check the brief's rules first. Whatever you use, make sure you understand every line, because the follow-up conversation will ask about it.
What if I run out of time?
Submit the working MVP with an honest README section on what is missing. A small thing that works beats a large thing that does not.
Summary: to do well on a software engineer take home assignment, keep the scope tight, make it easy to run, test the edges, and state your trade-offs. Then prepare for the live round separately.