Take-Home Assignments: How to Handle Them (and When to Say No)

Take-home assignments are controversial for a reason. Done well, they're a more humane alternative to a whiteboard interview — you get to think, iterate, and show your real work. Done badly, they're unpaid spec work that eats a weekend and produces no signal either direction. Knowing which you're looking at, and how to handle it, is the difference between a fair fight and a bad trade.

What Take-Homes Are Actually For

The best take-homes evaluate three things that are hard to see in a live interview:

• How you think when you're not on the spot. Does your work hold up when you have time to refine it?
• How you communicate decisions. A README explaining what you built and why is often more important than the code itself.
• What you choose not to do. Time-boxed work forces trade-offs. Picking the right corners to cut is a senior skill.

If a take-home is designed to test any of those three, it's probably legitimate. If it's designed to test how many hours of free labour you'll give them, you'll know from the scope.

How to Evaluate the Prompt

When the assignment arrives, read it twice and ask yourself four questions before you open your editor:

• How long is it supposed to take? Anything advertised as "3–4 hours" is usually 8. If it has no time limit, that's a flag — set your own.
• Does the output look productionizable? "Build a dashboard for our customer data" with no synthetic dataset is suspicious. Real test problems use synthetic or public data for a reason.
• Is there a review process described? "You'll present this in a 60-minute follow-up" is a good sign. "Send it over and we'll respond" is a worse one.
• What does the rubric look like? A good prompt tells you what they'll evaluate. A bad one leaves you guessing.

Negotiating the Scope

This is the move candidates underuse: you can push back on scope. A reasonable company will respect it; an unreasonable one will tell you everything you need to know.

Most hiring managers say yes, and the candidates who ask usually get evaluated more favourably — they've just demonstrated prioritisation, which is half of what they're testing for.

Executing the Work

Write the README first

Before you code, draft the README. What are you building, what trade-offs are you making, what's out of scope, what would you do with another day? If you can't articulate the problem and your approach in a page of prose, the code won't save you.

Time-box ruthlessly

Decide your budget before you start and commit to it. At the end of the budget, you ship what you have plus notes on what you'd do next. Candidates who spend 20 hours on a "4-hour" assignment don't look dedicated — they look like they can't scope.

Pick one thing to do really well

A small, polished solution beats a half-finished sprawling one every time. Reviewers can extrapolate quality, not finish messy work. If the prompt has five features, do two beautifully and document the other three clearly.

Add tests if the role warrants them

Not all of them — but the ones that cover the core logic. A single good test suite tells a reviewer more about your instincts than a thousand lines of code.

Leave the scaffolding visible

Commit history that shows iteration is almost always better than a single "initial commit." If it's a git repo, write commits that tell the story of how you got there.

Red Flags That Justify a No

• More than 8 hours of work with no compensation. At some point you're being paid below minimum wage for spec work.
• A problem that solves an actual business need they haven't already built. "Design our new onboarding flow" for a company that's been shipping for five years is an ask, not an interview.
• No NDA or scope limit. Anything you produce without terms can be reused.
• Request for your best existing client work. That's confidential to the people who paid for it.

How to Decline Without Burning the Bridge

A reasonable company will counter-offer. An unreasonable one will tell you that's how everyone is evaluated — which is your answer about whether to keep going.

The Follow-Up Conversation

If there's a review session, it matters more than the artifact. Be ready to:

• Defend decisions without being defensive.
• Acknowledge what you'd change if you had another day.
• Engage with critical feedback — disagreement is fine; dismissiveness is a career limiter.

The best candidates don't argue that their assignment is perfect. They have a considered view on its limits, and they can tell you what they'd prioritise next.

The Bottom Line

A fair take-home is a chance to do your best work on your own time. An unfair one is a signal about how the company treats its people — including you if you get hired. Scope the prompt before you code, time-box ruthlessly, write the README first, and push back on anything that smells like spec work. The way you handle the assignment is the assignment.