Take-Home Assignments: How to Scope, Build, and Present Them

A take-home assignment looks like a coding test, but reviewers mostly read it for judgement: what you chose to build, what you left out and whether you can explain why. Good engineers lose take-homes by over-building, by under-explaining, or by submitting something that will not run on the reviewer’s machine. All three are avoidable with a little discipline before, during and after the build.

Get the scope in writing before you write code

Most briefs leave things unsaid, deliberately or not. Ask before you start, in a single email, so the answers are on record:

• Time: is the stated effort, say “about four hours”, an expectation or just a deadline? When is it due?
• Constraints: required language or framework, allowed libraries, and whether in-memory storage is acceptable or a real database is expected.
• AI coding assistants: are they allowed, and should you say where you used them? Policies differ, and guessing wrong looks worse than asking.
• Evaluation: do correctness, structure, tests or the follow-up discussion carry the most weight?
• Submission: a private repository, a zip file or a deployed link, and who needs access.
• Next step: will there be a review call to walk through it?

A version you can send:

Thanks for sending the assignment. Before I start, a few quick questions. Is roughly four hours the expected effort, and is Friday the deadline? Is in-memory storage fine, or would you like a real database? Are AI coding tools allowed? And will there be a call to discuss it afterwards? I would rather build what you want to see than guess.

If nobody replies within a working day, write your assumptions at the top of the README and carry on.

Plan the work: thinnest working version first

Read the brief twice and split it into must-haves and nice-to-haves. Then budget the time. For a four-hour assignment, something like this works:

• 20 minutes: read, list requirements, write down assumptions and sketch the structure.
• Two hours: build the core flow end to end with the simplest storage that works.
• 55 minutes: tests for the core logic and the edge cases the brief mentions.
• 45 minutes: the README, a fresh-clone check and cleanup.

Get one complete path working before adding anything else. A small finished solution beats an impressive half-built one, because nobody can score code that does not run. Commit in small steps with messages that say what changed and why; some reviewers read the history to see how you work, and “final fix 3” tells them nothing.

Write the README your reviewer needs

The README is usually the first file a reviewer opens, and it is where your judgement is most visible. Keep it to a page or two:

1. What it does: two or three sentences, plus anything from the brief you deliberately left out.
2. How to run it: required versions and a single command, such as docker compose up or make run.
3. How to test it: one command, and what the tests cover.
4. Decisions and trade-offs: the three or four choices that shaped the solution, each with the alternative you rejected.
5. Assumptions: where the brief was ambiguous and what you assumed.
6. With more time: specific improvements, in priority order.
7. Time spent: honestly.

Each decision entry should be short and concrete. An illustrative example: “Stored bookings in SQLite rather than in memory, so data survives restarts during the demo. In production I would use PostgreSQL with a unique constraint on room and time slot, so the database itself prevents double bookings.” Those two sentences tell the reviewer you know the difference between a demo and a system.

Tests: enough to show judgement, runnable in one command

Nobody expects full coverage in an evening. They expect tests where they matter:

• the core business rule, such as the booking conflict check or the pricing calculation;
• the edge cases the brief names, plus the obvious ones it does not: empty input, duplicates, boundaries;
• one test of the main flow end to end, through the API or the command line.

Pin dependency versions, include any seed data, and make the test command work on a clean machine.

What not to build

Over-engineering is a common way for strong candidates to lose a take-home. Unless the brief asks for them, skip:

• microservices, message queues and Kubernetes manifests for a problem that fits in one process;
• authentication, user management and admin panels;
• interfaces and factories with a single implementation;
• caching added “for performance” with nothing measured;
• a polished interface when the brief is about an API.

Do not skip input validation, clear error messages, sensible structure and readable names. A workable rule: if the brief does not mention something and it does not make the core better, list it under “With more time” instead of building it. That shows you thought of it without spending your weekend on it.

Presenting and defending it in the review call

Prepare a five-minute walkthrough: the problem in one sentence, a short demo, the structure of the code, two or three main decisions and what you would change. Then expect three kinds of question:

• Why: “Why this data structure?” “Why not a queue here?” Answer with the trade-off you weighed, not with the tool’s popularity.
• What if: “What happens at a hundred times the traffic?” “What if two requests book the same slot at once?” Show where the design breaks and what you would change first.
• Change it now: reviewers often ask you to add a small feature or fix a bug live. This is how they confirm you wrote and understand the code. If you used AI assistance, you still need to explain every line.

Point out weaknesses before the reviewer finds them. “The conflict check is not safe under concurrent requests; with more time I would move it into a database constraint” turns a flaw into evidence of judgement.

Red flags, and how to push back politely

Most take-homes are fair. Some are not, and a few are not interviews at all. Be wary when:

• the task looks like real production work: a feature for the company’s actual product, their real data, a fix to their live codebase, or content for their marketing;
• the expected effort runs to several days, or the scope is a complete application with authentication, payments and an admin panel;
• it arrives before you have spoken to anyone at the company, with no review call planned;
• you are asked to deploy on your own paid cloud account, or to sign over rights to your work before any offer;
• completing it leads to a request for money for “training”, “certification” or “equipment”. That is a scam, and the guide to recruitment scams describes the pattern.

You can push back without sounding difficult. Ask for a smaller scope, or offer an alternative:

I am keen on this role and happy to do an assignment. I can give it about four hours this week. Could you tell me which parts you would most like to see, so I can focus there? Alternatively, I could walk you through a similar project on my GitHub, or do a live pairing session.

If the work would take more than a day, it is also fair to ask whether it is paid; some companies do pay for longer trial projects. Some will not adjust at all, and that is their call. Decide your own rule in advance, for example: “I do take-homes of up to half a day, for roles I want, after at least one conversation with the team.” A rule made calmly is easier to keep than a decision made while an exciting company waits for your answer.

Before you press submit

• Scope, deadline and AI-tool policy confirmed, or your assumptions written down.
• The core flow works end to end.
• Tests cover the main rule and the named edge cases, and run with one command.
• A fresh clone runs by following the README exactly.
• The README covers decisions, trade-offs, assumptions, “With more time” and time spent.
• No secrets, API keys or personal data anywhere in the repository or its history.
• The commit history reads like a sequence of sensible steps.
• A five-minute walkthrough rehearsed, including the weaknesses you plan to point out.

After submitting, keep the repository private unless the company says otherwise, since companies often reuse assignments, and ask before adding it to a public portfolio. The GitHub and portfolio guide covers what is worth showing publicly.