Take-Home Coding Assignments: How to Stand Out

A take-home assignment is a small project you complete on your own time as part of a hiring process. Many developers prefer them to live coding because they're closer to real work. But they're also easy to get wrong, either by overbuilding for days or by submitting something that works but tells the reviewer nothing about how you think.

What reviewers actually look for#

Reviewers typically spend a limited amount of time on each submission. They look for:

1. Does it work? Can they run it easily, and does it meet the requirements?
2. Is the code clean? Clear structure, naming and separation of concerns.
3. Is it tested? Meaningful tests for the important logic.
4. Can you explain your decisions? Usually through the README.
5. Did you follow instructions? Language, scope, submission format and deadline.

Fancy extras rarely make up for missing the basics.

Before you start#

• Read the brief twice. Highlight requirements, constraints and anything marked optional.
• Ask clarifying questions if something is genuinely ambiguous. It's a good sign, not a weakness. If you can't ask, write your assumptions down.
• Check the expected time. If the brief says "about 4 hours", treat that as a real limit. Spending several days on a small assignment is not a fair trade, and it can set unrealistic expectations.
• Check the deadline and plan when you'll work on it.

While you build#

Start with a working core#

Get the main requirement working end to end first, then improve it. A complete, simple solution beats an ambitious, unfinished one.

Structure the code like a real project#

• Separate concerns: for example routing, business logic and data access in a backend; components, state and API calls in a frontend.
• Use clear names; avoid clever one-liners.
• Handle errors and invalid input properly. Reviewers check this.
• Keep configuration and secrets in environment variables, never hard-coded.

Write meaningful tests#

You don't need 100% coverage. Focus on the business logic and the tricky edge cases. A few well-named tests show you think about correctness:

describe("splitBill", () => {
  it("splits evenly between people", () => { /* … */ });
  it("assigns leftover cents to the payer", () => { /* … */ });
  it("rejects a negative amount", () => { /* … */ });
});

Commit as you go#

A clear commit history ("Add order validation", "Handle empty cart") shows how you work. Avoid a single commit called "done".

Write a README that does the selling#

This is where you explain everything the code can't. Include:

## How to run
One or two commands, e.g. `npm install && npm test && npm start`.

## What I built
Short summary of features and what meets each requirement.

## Decisions and trade-offs
Why this structure, library or data model; what you'd choose at larger scale.

## Assumptions
Anything ambiguous in the brief and how you interpreted it.

## What I'd do with more time
Honest list: more tests here, pagination there, better error messages…

The "what I'd do with more time" section matters: it shows judgement and lets you stay within the time limit without looking careless.

Before you submit#

• Run it from scratch on a clean clone, following your own README.
• Remove dead code, debug logs and unused files.
• Check for secrets in the code and Git history.
• Submit on time, in the format they asked for.

The follow-up interview#

Many companies discuss the assignment in a later interview. Expect questions like "Why this structure?", "How would this handle 100 times more traffic?" or "Can you add this feature now?" Re-read your code before the call so it's fresh. Our guides on the interview process and system design basics help you prepare for the scaling questions.

Is it reasonable to say no?#

If an assignment looks like unpaid real work (for example "build this feature for our product"), or would clearly take days, it's fair to ask whether there's a shorter version or an alternative such as a live session. How a company responds tells you something about how it treats people.

Key takeaways#

• Follow the brief and respect the time estimate.
• Build a working core first, then improve structure, error handling and tests.
• Use the README to explain decisions, assumptions and what you'd do next.
• Test it from a clean clone before submitting.
• Prepare to explain and extend your code in the follow-up.

#interviews