Take-Home Assignment Guide

The take-home assignment is the interview format everyone loves to hate — and the one where prepared candidates quietly dominate. Why? Because most submissions fail on the boring stuff: no README, no tests, unexplained choices, or a scope explosion that never quite works. Beat the boring stuff and you're already in the top slice of the pile.

The key idea: a take-home is not a test of how much you can build; it's a test of how you work. Reviewers grade judgment — scoping, communication, and finishing — far more than raw code volume.

The submission checklist

1. Clarify before you start. Time expectations, ambiguous requirements, evaluation criteria. Asking one sharp clarifying question signals seniority; guessing wrong signals the opposite.
2. Timebox ruthlessly. If they say "a few hours," plan for that, not a weekend. Decide your scope in the first fifteen minutes and write it down.
3. Write the README like it matters — because it does. How to run it, what you built, key decisions, and — critically — what you'd do next with more time. That last section converts "unfinished" into "deliberately scoped."
4. Meet the spec exactly before extending it. A complete core beats a half-integrated bonus feature every time.
5. Test the happy path and one sad path. Even a couple of tests signal craft.
6. Do a clean-machine run. Fresh clone, follow your own README. If it doesn't run, nothing else matters.

The scope triangle

You get two of three: features, polish, time. Choose consciously and say what you chose. "I prioritised a correct core flow over the export feature; the README outlines how I'd add it" is a senior answer. Silently shipping a broken extra is a junior one.

Start the walkthrough defence on day one. Keep a short decision log as you build — "chose X over Y because Z," two lines per decision, in a notes file or your commit messages. When the live review arrives, you'll reconstruct your reasoning in seconds instead of reverse-engineering your past self under pressure. Reviewers' favourite probe is "why did you do it this way?", and the candidates who answer crisply are simply the ones who wrote the answer down while it was fresh. The log also demonstrates the working style every team claims to want: deliberate, documented, and easy to collaborate with.

What to avoid

• Gold-plating. Reviewers can tell when a "three-hour" assignment took twelve, and some companies explicitly weigh that.
• Framework-hopping to show off. Boring, familiar tools let your judgment show; exotic ones make reviewers fight your setup.
• Forgetting that you'll defend it live. Many loops include a walkthrough session — expect second-round-style drilling on every decision you made.

FAQ

What if the assignment is unreasonably large? It's fair to ask about expected effort and even to push back politely: "This looks like a multi-day scope — is a smaller slice acceptable?" Their answer tells you a lot about the company.

Should I use AI tools while building it? Follow the company's stated policy and be ready to explain every line as your own — the walkthrough exists precisely to verify authorship. Solid fundamentals, like those in the interview study guide, are what carry you through that conversation.