Take-Home Coding Assignment Guide 2026: How to Stand Out

A take home coding assignment is a small project a company asks you to build on your own time, usually scoped for two to four hours, and then grades against a rubric before a follow-up review call. To stand out, clarify scope first, finish the core requirements cleanly inside the time box, write a few meaningful tests, and ship a README that explains your trade-offs and what you cut. Reviewers reward judgment and clarity far more than extra features.

Key Takeaways

• A non-running submission usually ends your candidacy. Make setup work in one or two commands before you polish anything.
• Reviewers typically grade correctness, code structure, tests, error handling, written communication, and scope judgment. Feature count is not on the list.
• Respect the time box. Going far past it signals poor prioritization, and a clear "what I cut" section often scores better than the extra work.
• The README is graded. Reviewers often read it before opening a source file.
• The review call often decides the outcome. You must explain and extend every line you submitted.
• You can decline. Assignments that need more than a day, have no criteria, or look like unpaid production work are reasonable to push back on.

What Is a Take-Home Coding Assignment?

A take-home coding assignment is an asynchronous technical interview in which you build a small, realistic feature or service in your own environment and submit it, usually as a Git repository. Common prompts include a REST API with a few endpoints, a small React app that consumes an API, a data-processing script, or a CLI tool with clear inputs and outputs.

Companies use take-homes because they look more like the actual job than a timed algorithm puzzle. They show how you structure code, name things, write tests, and explain decisions in writing. They are popular at startups and product companies and less common as a first filter at the largest tech companies, which still lean on online assessments and live rounds.

Take-home vs live coding

A take-home suits careful, structured workers better than a stopwatch does, but it costs you an evening or more.

How Are Take-Home Assignments Graded?

Take-home assignments are graded against a rubric, and the first gate is simple: does it run and do the core thing? Most teams treat a broken setup or a failing core path as an automatic fail, then rank the passing submissions on quality. Rubrics vary by company, but most of them map to the categories below.

This is an illustrative reviewer rubric, a synthesis of common grading categories rather than any single company's scorecard. The weights are our own and will differ by team.

Two things stand out. First, nothing in that table rewards extra features. Second, a full fifth of the score lives in writing, not code. This matches what reviewers look for in live coding interviews too: clear reasoning beats raw output.

How Long Should a Take-Home Take?

A take-home should take roughly the time the company suggests, which for most reasonable assignments is two to four hours of focused work. If the instructions give no limit, ask the recruiter. Then plan your hours before you write code.

Clarify scope before you start

Ambiguity in a take-home prompt is often deliberate. Reviewers want to see whether you ask good questions or make sensible, documented assumptions. Send one short email within a day of receiving the assignment:

Hi [Name],

Thanks for sending the assignment. A few quick questions before I start:

1. Is the suggested 3-hour time box a hard limit or a guideline?
2. Are AI coding assistants allowed? If so, should I note how I used them?
3. For the persistence layer, is an in-memory store acceptable, or do you expect a real database?
4. Is there a preferred language or framework, or is my choice fine?

I plan to submit by Thursday at 5pm. Happy to adjust if that does not work.

Thanks,
[Your name]

If you get no answer, pick the simplest reasonable interpretation and write it down in your README. A documented assumption is far safer than a silent wrong guess.

A time-box plan for a 4-hour assignment

The buffer step catches the most embarrassing failures. Clone your repo into a new folder, follow your README exactly, and run the tests. If anything fails there, it fails for the reviewer too.

What to Cut When Time Runs Short

Every time-boxed take-home forces trade-offs, and the reviewer wants to see you make them on purpose. Use this decision table when you hit the halfway point and realize you will not finish everything.

The rule underneath the table: cut breadth, never depth. A small, finished, tested core reads as senior. A wide, half-working app reads as someone who did not prioritize.

Code Structure and Tests That Reviewers Like

Good take-home structure is boring on purpose. A reviewer should open your repo and understand where things live within a minute. For a small backend service, a layout like this works in most languages:

order-service/
  README.md
  package.json
  src/
    index.ts            # starts the server
    routes/orders.ts    # HTTP layer only
    services/orders.ts  # business rules
    store/orders.ts     # persistence behind an interface
    types.ts
  tests/
    orders.service.test.ts
    orders.routes.test.ts

The key idea is separation: HTTP handling, business logic, and storage live in different places. That makes your logic easy to test without spinning up a server, and it gives you an obvious answer when the reviewer asks how you would swap in a real database. Our backend engineer interview guide covers the same layering in more depth.

Tests should target behavior, not implementation details. Here is what a focused test looks like for a discount rule:

import { describe, it, expect } from "vitest";
import { applyDiscount } from "../src/services/orders";

describe("applyDiscount", () => {
  it("applies 10% off orders of 100 or more", () => {
    expect(applyDiscount(200)).toBe(180);
  });

  it("leaves orders under 100 unchanged", () => {
    expect(applyDiscount(99.99)).toBe(99.99);
  });

  it("rejects negative totals", () => {
    expect(() => applyDiscount(-5)).toThrow("Total must be non-negative");
  });
});

Three tests, three behaviors: the happy path, the boundary, and the error. That pattern, repeated across your core logic, is what a reviewer means by "meaningful tests."

A few more structure habits that score well:

• Commit in small, readable steps with clear messages. Some reviewers read the Git history to see how you work.
• Remove debug logs, unused imports, and commented-out code before submitting.
• Run your formatter and linter. Inconsistent formatting is an easy, avoidable deduction.

A README Template You Can Copy

The README is the cover letter for your code. Keep it to roughly one screen and lead with how to run the project. Copy this template and fill it in:

# Order Service

A small REST API for creating and listing orders with discount rules.

## Run it

    npm install
    npm start        # http://localhost:3000

## Test it

    npm test

## What I built

- POST /orders creates an order and applies discount rules
- GET /orders lists orders with pagination
- Input validation with clear 400 errors

## Assumptions

- Prices are in USD and stored as integer cents to avoid float errors
- An in-memory store is acceptable (confirmed with recruiter on Monday)

## Trade-offs

- Storage sits behind an OrderStore interface, so swapping in Postgres is one new class
- Chose plain Express over a larger framework to keep setup to one command

## What I cut (3-hour time box)

- Authentication
- Persistent database
- Docker setup

## What I would do next

1. Add Postgres with migrations
2. Add idempotency keys on POST /orders
3. Add request logging and basic metrics

## AI usage

Used an AI assistant for boilerplate test scaffolding. All logic written and reviewed by me.

The "What I cut" and "What I would do next" sections do most of the work. They show the reviewer you saw the gaps, chose them deliberately, and know how to close them. Include the AI usage note only if the company allows assistants or asked for disclosure.

How to Prepare for the Follow-Up Review Call

The follow-up review call is a 45 to 60 minute session where one or two engineers walk through your submission with you. It exists to confirm two things: that you wrote and understand the code, and that you can reason about it under light pressure. Strong submissions lose offers here when the candidate cannot explain their own choices.

Expect these kinds of questions:

• Walk us through the structure. Why did you split it this way?
• What happens if two requests update the same order at once?
• How would this change at 100 times the traffic?
• Which part are you least happy with?
• Let's add a feature: support refunds. Show us where it goes.

That last one is common. The live extension turns the call into a short pair programming session, and the same skills apply: narrate your plan, write the smallest change first, and run the tests. If you get stuck, say what you are checking out loud rather than going quiet; our guide on thinking out loud in coding interviews has phrases that help.

Prepare the day before. Reread your code as if someone else wrote it, list its three biggest weaknesses, and decide how you would fix each. Then pick the two most likely next features and sketch where they would go. Walking in with your own critique ready is the single best move in this round.

Can You Use AI on a Take-Home Assignment?

Whether you can use AI on a take-home depends entirely on the company's stated policy, and policies differ widely. Some teams explicitly allow assistants, some ask you to disclose usage, and some forbid it. If the instructions are silent, ask in your scoping email.

What does not change is the review call. Whatever produced your code, you need to own it line by line. For how companies try to detect AI-written submissions, see do take-home coding assignments detect AI, and for loops that openly allow assistants, our AI-enabled coding interview guide covers what changes.

When Should You Decline a Take-Home?

You should decline, or push back on, a take-home when the cost to you is out of proportion to the signal the company gets. Your time has value, and a reasonable company will usually offer an alternative. Consider declining when:

• The assignment clearly needs more than a full day of work, with no compensation offered.
• It looks like real production work for their product, such as building a feature they would ship.
• It arrives before any conversation with a human, as a mass first filter.
• There are no stated requirements, evaluation criteria, or time expectations, and the recruiter will not clarify.
• You are already in late stages elsewhere and cannot spend the time without hurting other processes.

When you decline, offer something in its place:

Thanks for sending this. I'm very interested in the role, but I'm in several
processes and can't commit 15+ hours right now. Would a live coding session or
a walkthrough of a project I've already built work instead? Here's a repo I
maintain that shows similar backend work: [link].

Some companies will agree. If they refuse, that tells you how the team values engineers' time. For more on balancing multiple loops, see our software engineer job search strategy.

Common Red Flags Reviewers See

These are the patterns that most often push a take-home from "pass" to "no." Nearly all of them are avoidable with a final check.

Notice how many of these are about finishing, not ability. Competent engineers fail take-homes mostly by skipping the last thirty minutes of checks, a theme we also see in why qualified candidates fail technical interviews.

Final Submission Checklist

Run through this list before you hit send:

1. Fresh clone, follow README, project runs.
2. All tests pass with one command.
3. Every required behavior works end to end.
4. Invalid input returns a clear error instead of a crash.
5. No secrets, debug logs, or commented-out code.
6. README covers run steps, assumptions, trade-offs, cuts, and next steps.
7. Commit history is readable.
8. You submitted within the agreed time window.
9. You have reread the code and listed its weaknesses for the review call.