Take-Home Assignment: How Much Time to Spend and When to Say No

A take-home assignment is a task a company sends you to complete on your own time: a small app, a data analysis, a design exercise, a bug to fix in a sample repo. The hard part is rarely the task itself. It's deciding how much time to spend, whether to do it at all, and what to hand in so the reviewer sees your thinking. This guide covers what to ask before you start, how to time-box the work, when declining is reasonable, and what a good submission includes.

Ask these questions before you start

The assignment brief often leaves out what matters most. A short email to the recruiter usually gets answers, and asking is a normal part of the process. If you're still on the recruiter screening call, ask there.

How much time do you expect it to take? If the answer is "as long as you like", ask what a typical submission looks like.
What will you evaluate? Code structure, tests, correctness, product thinking, communication? This tells you where to put your hours.
What's the deadline, and is it flexible? Many companies will give you a week if you ask.
Will we discuss it in a follow-up interview? If yes, your write-up matters even more.
Which tools are allowed? Language and framework choice, libraries, and whether using AI assistants is fine. Policies differ between companies, so ask rather than guess.
Is it paid? Some companies pay for longer assignments. It's a fair question for anything beyond a few hours.

Write the answers down. They're your scope.

How much time to spend on a take-home assignment

Decide your budget before you open the editor, and write it down. A reasonable starting point is the time the company stated, with a little extra for the write-up. Then check whether the budget is realistic: skim the whole task, list the parts, and estimate each one. If your estimate is twice the stated time, that's useful information. Tell the recruiter which parts you'll prioritise, or ask whether a smaller version is acceptable.

A few habits keep the time from expanding:

Do the core first. Get the main requirement working end to end before polishing anything.
Set checkpoints. At the halfway mark, check what's done and cut what won't fit.
Keep a list of "with more time" items as you go. They go into your README instead of into extra evenings.
Stop at the budget. An honest note about what you didn't do is better than a week of unpaid work you'll resent.

Spending more time than asked can look like commitment, but reviewers usually compare submissions against the scope they set. Overbuilding can also make your code harder to review. If you're doing this while employed, the evening hours are limited anyway; our guide to job searching while employed has ideas for fitting interview work around a job.

When to decline, and how

Declining a take-home isn't a failure. It's a decision about where your time goes. It's reasonable to say no, or to ask for an alternative, when:

The task would take several full days and isn't paid.
It looks like real production work: a feature for their actual product, or analysis of their real business data.
It comes before any human conversation, and you have other processes that are further along.
You already have several assignments in progress and can't do this one well.
The scope keeps growing after you've started.

Some companies offer an alternative, such as a live pairing session or a walkthrough of code you've already written. You won't know unless you ask. A short, polite message works:

Thanks for sending this over. I'm interested in the role, but I can't commit [estimated time] to the assignment right now. Would a live coding session or a walkthrough of a past project work instead? If not, I understand, and I'd be glad to stay in touch for future roles.

Some will say no and end the process. That's their choice, and yours is equally valid. Turning down tasks you can't do well also protects you from the tiredness that builds up over a long search; see job search burnout.

What to submit

The code is only part of the submission. The reviewer may have limited time and no context beyond the brief, so make their job easy.

A README that covers:

How to install and run it, in as few steps as possible.
What you built and which requirements it covers.
Key decisions and trade-offs: "I used SQLite to keep setup simple; in production I'd use PostgreSQL."
What you'd do with more time (your list from earlier).
Roughly how long you spent.
Any assumptions you made where the brief was unclear.

In the code itself:

A few meaningful tests around the core logic, rather than many shallow ones.
Clear, small commits, if you're submitting a repository. They show how you work.
No secrets, API keys or personal data in the repo.
Consistent formatting and naming. Run a formatter and linter before you send it.

Before submitting, clone or unpack your own submission into a fresh folder and follow your README exactly. Fix whatever breaks.

After you submit

Send a short note with the link, and ask when you can expect feedback. Log the date in your job application tracker, and follow up once if the date passes. If you get rejected, it's fair to ask for feedback; some companies share it, many don't.

Take-homes cost time, so it helps to have enough good opportunities that you can be selective about which ones you take on. Hot Jobs can help keep that pipeline full: it sends new postings from 390+ company career pages, plus two remote boards, to Telegram, filtered by the roles and regions you choose. It won't do the assignment for you. €3, paid once. Connect the bot