Take-Home Assignment: How Long It Should Take, Whether to Do It, and How to Win It (2026)
The email arrives and it is friendly. They enjoyed the conversation, they would like to see how you work, and there is a short exercise attached. Should take three or four hours. You open the brief on a Tuesday evening and by the second paragraph you are doing arithmetic: the data needs cleaning, the thing they described needs a working front end, and the part they called a nice-to-have is most of the job. It is not three hours. It was never going to be three hours. And the only lever you appear to have is your weekend.
Quick answer
Quick answer: a take-home assignment (or work sample test) is a small piece of real work you complete on your own time and submit for review. Three hours is the ceiling for an unpaid one, because almost all of the signal is there by hour two while the cost to you keeps climbing. Do it if it is capped, comes after a human conversation, and is a toy problem rather than a live deliverable. Negotiate at four to eight hours. Decline at ten-plus unpaid hours or if it is on their roadmap. And spend 30 of your 180 minutes on the README, because it is the first thing opened and the last thing most candidates write.
What is a take-home assignment?
A take-home assignment is a small, realistic piece of work an employer asks you to complete on your own time and submit for review. You will see the same thing called a work sample test, a take-home test, a take-home project, a take-home exercise, a coding challenge or a take-home case study. The artefact changes by field. The format does not: a brief, a time expectation, a deadline, and a submission that gets scored.
It normally sits in the middle of a process, after a screening interview and usually after a first conversation with the hiring manager. It exists because it is the only stage that measures output rather than the ability to talk about output.
Which makes it genuinely good news for more people than realise it. If you interview worse than you work, this is your stage. If you are a career changer whose resume does not carry the story on its own, this is where the resume stops mattering: see the career change resume for the stage before it. And if your best evidence is the thing you can build rather than the thing you can narrate, an assignment is the one format that asks for exactly that.
The problem is not the format. It is that the format has no natural limit. A well-designed three-hour exercise and an unpaid twelve-hour project arrive in your inbox looking identical, and the whole skill is telling them apart quickly.
How long should a take-home assignment take?
Three hours is the ceiling for an unpaid exercise, and most of what can be learned is already there by hour two.
The reason is in the chart above. The signals that matter appear early: did you understand the brief, can you scope, does the thing run, can you explain a tradeoff. None of those need six hours. What extra hours buy is polish and breadth, which is precisely the part a reviewer skims. So information per hour collapses while your cost rises in a straight line, and past a point the exercise stops measuring skill and starts measuring who had eight uncommitted hours available, which is a fact about someone's circumstances.
Assume double the stated estimate
Should you do it, negotiate it, or decline it?
Most people answer this on feeling, usually somewhere between flattered and resentful. There are six signals that actually predict whether the hours are well spent.
The clearest single test is the roadmap test. Ask whether shipping your submission would save them a sprint. If the answer is yes, you are not being assessed, you are working, and the intent behind it does not change the arithmetic.
The option people forget exists is the middle one. Negotiating is normal and reasonable employers say yes to it, because a hiring manager who wants six hours of your time mostly wants the first two.
Script: narrowing the scope
"Thanks for sending this. Looking at the brief, I think the full version is closer to a day than an afternoon. Would it work if I kept it to three hours and focused on [the core part], and skipped [the parts you are cutting]? Happy to talk through how I would approach the rest on a call."
This works because it concedes nothing about willingness and everything about scope, and it hands them a concrete proposal rather than a complaint. It also demonstrates the exact skill the exercise is testing.
Script: asking whether it is paid
"Happy to do this. Given the scope looks like a day of work rather than a couple of hours, is this a paid exercise? If not, I would suggest narrowing it to [the core part] so it fits in three hours."
Ask it plainly and without apology. A company that reacts badly to this question has told you something genuinely useful about how it will treat your time once you work there, for the price of one email.
Script: declining without ending the relationship
"Thank you for sending this over. I am mid-process with a couple of other companies and I am not able to commit ten unpaid hours to any single one. I would very happily do a two-hour version of the core problem, or a live ninety-minute session where you watch me work on it. Either works for me if either works for you."
Decline the scope, not the process, and always offer two alternatives. Send it promptly: a fast clear no is respected, while a week of silence followed by a withdrawal is remembered. Some companies will end things there, and that is a reasonable trade rather than a loss.
Read the brief as evidence about them
Before you plan a single hour, read the brief for what it says about the team that wrote it. A group that cannot scope a three-hour exercise is unlikely to scope your first quarter, and you are being handed a free sample of how they think.
If any of those six are missing, ask. It costs one email and it is a legitimate question: "So I can keep this to the time you suggested, could you tell me what you will be looking at, and what I should treat as out of scope?"
And send your clarifying questions early, within a few hours of receiving the brief, so that waiting on an answer does not eat your deadline. Two sharp questions are scored positively at most companies, for the same reason they are valued in the job: spotting ambiguity before spending a day on it. Keep them to the ones that genuinely change what you would build, such as whether this is optimising for accuracy or speed, whether the data should be treated as trustworthy, or whether this is a throwaway prototype or version one of something real.
How to spend a three-hour cap
Only about half of the budget is for building, and that is the entire discipline of this format.
The step that saves the whole thing is the second one: write down what you are not going to do. A five-line plan with an explicit out-of-scope list is what stops three hours becoming eight, because without it every new idea feels mandatory and there is no written commitment to point at when you are tempted at hour four.
On the build itself: complete and small beats broad and broken. One path that works end to end lets a reviewer extrapolate. Four half-built paths let them conclude nothing, and they will not give you the benefit of the doubt on any of them.
What reviewers actually look at
Here is the part almost nobody believes until they have been on the other side of it. A reviewer opens the README first, tries to run the thing, and spends ten to twenty minutes in total. Not an evening. Not line by line.
The mismatch in the bottom two rows is where take-homes are lost. And the last row is worth being explicit about: extra features are worse than neutral. When a brief says no styling and no authentication and you deliver both, you have not shown enthusiasm. You have shown that a written scope limit does not survive contact with you, which is exactly what a well-designed exercise is built to detect.
The productive version of that instinct costs five minutes instead of two hours: write three lines saying what you would build next, in priority order, with a sentence on why. Same ambition, same understanding of the problem, and it reads as judgment rather than as scope creep.
The README is the exam
Thirty of your 180 minutes, and a wildly disproportionate share of the outcome. Six headings, in this order.
"What I left out, and why" is the highest-value paragraph in the entire submission. Every capped submission is incomplete by construction, so the only question is whether your incompleteness reads as a shortfall or as a decision. Tie each cut explicitly to the time limit and the difference is total.
Two mechanical things that decide more outcomes than they should. Clone it fresh and run it, because "it works on my machine" is not a defence, it is the thing being tested. And do not apologise. "Sorry it is rough, I ran out of time" instructs the reviewer how to read everything that follows, and they will take the instruction.
The decisions and tradeoffs section is where seniority shows, and the format matters: name the choice, name the alternative you rejected, and say why. That structure is the same reasoning shape that makes a STAR answer work in a live round, and quantifying the outcome helps here exactly as it does on a resume.
Can you use AI on a take-home assignment?
Use it as you would in the job, follow the brief if it says anything, and be ready to defend every line. Most employers have stopped pretending it is not used, and a growing number say explicitly that it is allowed, because banning it is unenforceable and testing for its absence measures nothing anyone cares about.
If they ask you to disclose what you used it for, answer accurately. A mismatch discovered later reads as dishonesty rather than as a tooling preference, and that is a much larger problem than any amount of generated code.
The real constraint is not policy, it is the review call. Take-homes are nearly always followed by a conversation where someone asks why you structured it that way, what happens if the input volume doubles, and what you would change first. Work you did not reason about collapses immediately under those questions, and it collapses worse than a smaller submission you fully understood would have. So generate what you like, then read it, cut whatever you cannot defend, and make sure the tradeoffs in your README are decisions you actually made. Our wider view on where automation belongs in hiring is in AI resume screening, and it is the same principle from the other side of the table.
After you submit
Expect the review call, and prepare for it properly, because it is where the offer is actually decided. Reread your own submission an hour beforehand, since you will have forgotten why you made half the choices, and have an answer ready for the three questions that always come: why this approach, what would break at ten times the scale, and what you would do next. Preparing for a job interview covers the rest, and the next round is often a panel interview.
Send a short note with the submission and nothing more elaborate. Two lines: here it is, kept to the cap, the README covers what I cut and why, happy to walk through it. The same logic as a thank you email after an interview, which is to say specific and short.
Then expect it to be slow. Submissions are slower than interviews for a structural reason: nothing is scheduled, so nothing forces a decision, and your work sits in a queue behind live delivery. how long it takes to hear back applies, with a few extra days. Follow up once, on the date they named or at ten days if they named none, and ask something specific rather than checking in. If you are rejected, ask for one concrete thing rather than general feedback.
Being ghosted after an unpaid assignment is a genuine failure on the employer's side, and it is a fair reason to be more sceptical next time. If the whole process felt strange from the beginning, ghost jobs covers how to spot a role that was never really open, and why you are not getting interviews covers the earlier stage where most applications actually stop.
Make sure your resume gets you to this stage at all
A take-home is the stage where your work speaks for itself. You only reach it if the resume screen goes your way first. Paste your resume and the job description into Rankid for a 0-100 match score, the requirements you have evidenced, and the keywords you are missing. One check free, no signup.
Check your resume freeFor employers: designing one that does not cost you your best candidates
A work sample is the most predictive stage most companies have. It is also the stage where the strongest applicants leave first, and those two facts are usually held by different people in the same organisation.
Two of those eight carry most of the weight. Test the cap on your own team, timed, before you send it to anybody: authors know the codebase, the data and the intended answer, and candidates reliably take about twice as long. And write the rubric before the first submission arrives, because a rubric written afterwards is a rationalisation of a preference. An interview scorecard is the right instrument, and skills-based hiring covers how a work sample fits against the other ways of assessing capability.
The fairness point deserves stating without hedging. An unpaid eight-hour exercise does not select for skill, it selects for eight uncommitted hours, which quietly filters out anyone with caring responsibilities, a second job, or a current role with real demands. None of those correlate with being good at the work. So check completion rates by group and treat it as any other selection step: adverse impact applies here as much as to a test or an interview, and it is a candidate experience question at the same time.
Finally, the commercial argument, since it is the one that tends to move decisions. Drop-off at this stage is not random attrition. The first people to decline a long unpaid exercise are the ones holding competing offers, because they can afford to, which means the longer your assignment, the weaker your shortlist. That makes length a hiring decision rather than an administrative one, and it belongs in the same conversation as cost per hire. Assignments should also only ever reach a shortlist you already believe in: shortlisting candidates from resumes and resume screening criteria cover the stage that has to come first, and the hiring process covers where this one sits overall.
Send assignments to a shortlist worth reviewing
Upload your applicants and the job description. Rankid scores every candidate against the real requirements and shows the evidence behind each score, so your take-home reaches the people worth an evening of their time and an hour of yours. First 5 resumes free, no signup.
Try bulk screening freeFrequently asked questions
What is a take-home assignment?
A take-home assignment is a small, realistic piece of work an employer asks you to complete on your own time, then submit for review. You will also see it called a work sample test, a take-home test, a take-home project, a take-home exercise, a coding challenge or a take-home case study, and while the artefact differs by field the format is identical: a brief, a time expectation, a deadline, and a submission that gets scored. It normally sits in the middle of a hiring process, after a recruiter screen and usually after a first conversation with the hiring manager, and it exists because it is the only stage that measures output rather than the ability to talk about output. That makes it genuinely good news for a lot of candidates, particularly people who interview worse than they work, career changers whose resume does not carry the story, and anyone whose strongest evidence is the thing they can build rather than the thing they can narrate. The problem is not the format. It is that the format has no natural limit, so a well-designed three-hour exercise and an unpaid twelve-hour project arrive in your inbox looking exactly the same.
How long should a take-home assignment take?
Three hours is the practical ceiling for an unpaid exercise, and most of what an employer can learn is already there by hour two. The reason is that the useful signals appear early: whether you understood the brief, whether you can scope, whether the thing runs, whether you can explain a tradeoff. None of those need six hours to demonstrate. What extra hours add is polish and breadth, which is exactly the part a reviewer skims. So the marginal information per hour collapses quickly while the cost to you keeps rising in a straight line. That asymmetry is the whole argument. Anything beyond three hours should either be paid or be replaced by a live session, and anything beyond about eight hours unpaid is not really an assessment at all: at that point the exercise mostly measures who had eight uncommitted hours available, which is a fact about someone's circumstances rather than their ability. One practical note if a brief gives no estimate at all: assume the true cost is roughly double whatever the author imagined, because assignment authors consistently underestimate their own exercises.
Should you do a take-home assignment?
Do it when the cap is three hours or less, it comes after you have spoken to a human, the task is a toy version of the work rather than a real deliverable, they told you how it is scored, and you genuinely want this specific job. Under those conditions it is the best stage in the whole process for you, because it is the one place where what you produce outweighs how well you interview. Negotiate first when the estimate is four to eight hours, the brief is vague, no evaluation criteria were given, or it arrives before any conversation. Negotiating is the move people forget exists: you can propose narrowing the scope to the core part, or offer a live session instead, and a reasonable employer will say yes. Decline when any single one of these is true: ten or more unpaid hours, the task is a live item on their roadmap, they will not tell you how it is evaluated, they want to keep or use the work regardless of outcome, or they are asking before a single human has spoken to you. The roadmap test is the clearest one. If shipping your submission would save them a sprint, you are not being assessed, you are working.
Should take-home assignments be paid?
Anything beyond about three hours should be paid, and paying for it is the clearest signal that an employer has thought about the exercise properly. The argument is not primarily moral, it is about what payment does to design. An employer who has to pay for six hours immediately asks whether they need six hours, and the answer is almost always no, so the assignment gets shorter and sharper. Payment also removes the selection effect that is the real problem with long unpaid exercises: an unpaid eight-hour task filters for people who have eight uncommitted hours, which quietly excludes candidates with caring responsibilities, a second job, or a current role with genuine demands, none of which correlate with being good at the work. As a candidate, it is entirely reasonable to ask, and asking well is easy: 'Happy to do this. Given the scope looks like a day rather than an afternoon, is this a paid exercise, or could we narrow it to the core part?' A company that reacts badly to that question has told you something useful for the price of one email.
Is a take-home assignment a good sign?
Usually yes, with one specific exception. Assignments are expensive for employers to set and to review, so a company that sends you one has generally decided you are a serious candidate rather than a maybe. It also almost always sits after the earlier filters, so reaching it means the resume screen and at least one conversation went your way. There is a second reason to be pleased: an assignment is the stage most likely to correct an unfair earlier impression, because it measures the work instead of the performance, which is why it tends to favour candidates who are stronger than their interviewing. The exception is when the assignment arrives as the very first step, before any human has spoken to you. That is not a signal of interest, it is a filter applied at volume, and it inverts the normal economics by making the candidate spend first. Treat a step-one assignment as a much weaker signal, and be correspondingly more willing to ask what the process looks like after it.
What if the take-home assignment takes longer than the stated time limit?
Stop at the limit, submit what you have, and say clearly what you cut. This is counterintuitive and it is genuinely the higher-scoring choice at any well-run company, because working to a stated constraint is one of the things the exercise is measuring. A submission that says 'I stopped at three hours as asked; here is what I deliberately left out and why' demonstrates scoping judgment, which is a senior trait, and it is the exact behaviour they want on the job when a deadline collides with an ambition. Quietly spending nine hours on a three-hour brief demonstrates the opposite, and it is more visible than people think: reviewers who set the cap have a good sense of what three hours produces. If you did overrun, be honest about it rather than hiding it, because being caught understating your hours is far worse than the overrun itself. The one thing not to do is apologise for the state of it. 'Sorry it is rough, I ran out of time' tells the reviewer how to read everything that follows, and they will oblige.
Can you ask clarifying questions about a take-home assignment?
Yes, and you should, in almost every case. Asking two sharp questions before you start is scored positively at most companies, for the same reason it is valued in the job: it is evidence that you spot ambiguity before you spend a day building the wrong thing. It also protects you, because the single most expensive mistake on a take-home is a confident answer to a question nobody asked. Send the questions early, ideally within a few hours of receiving the brief, so that waiting for a reply does not eat your deadline, and keep them to two or three that genuinely change what you would build. Good ones look like: is this optimising for accuracy or for speed of delivery? Should I assume the data is trustworthy or handle bad rows? Is this a prototype to be thrown away or the first version of something real? Bad ones are questions the brief already answers, or process questions like how long it should take when the brief has told you. If they refuse to answer or say to use your judgment, that is fine and it is also information: write your assumption down in the README and move on.
How do you politely decline a take-home assignment?
Decline the scope, not the process, and offer an alternative in the same message. Almost nobody is annoyed by a candidate who says no to twelve hours and yes to two. A version that works: 'Thank you for sending this over. I am interviewing with a couple of other companies at the moment and I am not able to commit ten unpaid hours to any single process. I would very happily do a two-hour version of the core problem, or a live ninety-minute session where you watch me work on it. Either is genuinely fine by me if one of them works for you.' That message is polite, specific, gives them two easy yeses, and does not lecture anybody. Send it promptly rather than sitting on the brief for a week, because a fast, clear no is respected while silence followed by a withdrawal is remembered. And accept that some companies will end the process there. That is a legitimate outcome and it is usually a good trade: a company that will not flex on ten unpaid hours at the interview stage is telling you something reliable about how it will treat your time later.
What do reviewers actually look at in a take-home assignment?
They open the README first, they try to run it, and they spend ten to twenty minutes total. That is the whole reality, and almost every mistake candidates make follows from not believing it. In practice the order is: read the README to understand what you did and why, attempt to run it exactly as documented, skim the structure of the work for clarity, look at one or two specific decisions in detail, and form a view. What that means is that the highest-return hour of your time is the one you spend writing up your assumptions, your tradeoffs and what you deliberately left out, because that is the part guaranteed to be read closely. And the lowest-return hours are the ones most people spend most heavily: visual polish, and features beyond what the brief asked for. Extra features are worse than neutral. When a brief says no styling and no authentication and you deliver both, you have not shown enthusiasm, you have shown that a written scope limit does not survive contact with you, which is precisely what a well-designed exercise is built to detect.
Should you go beyond what the take-home brief asks for?
No. Do exactly what was asked, do it well, and put everything else in a short 'what I would do next' section. This is the single most common way strong candidates lose a take-home, and it feels so much like diligence that it is hard to resist. The reasoning is simple: a brief with a scope limit is a test with two questions in it, one about the work and one about whether you can work to a constraint. Building the extra dashboard answers the first and fails the second. There is also a practical cost, because every extra feature is time not spent on the README, on making the thing run cleanly, or on the tradeoff paragraph that actually earns the interview. The productive version of the same instinct is to write it down: three lines saying what you would build next, in priority order, with a sentence on why, shows the same ambition and the same understanding of the problem, costs you five minutes instead of two hours, and reads as judgment rather than as scope creep.
What should the README for a take-home assignment include?
Six headings, and they take about thirty minutes to write. What this is: two sentences on what you built and what it does. How to run it: the exact commands, copy-pasteable, tested from a fresh clone rather than from your working directory. Assumptions I made: the ambiguities in the brief and which reading you chose, which converts every guess you made into a visible decision. Decisions and tradeoffs: three choices you faced, the alternative you rejected, and why, which is the clearest seniority signal available to you in the whole submission. What I left out, and why: the scope you deliberately cut, tied explicitly to the time cap. And with another day: three specific next steps in priority order. The fifth section is the one that changes outcomes, because it converts an incomplete submission, which every capped submission is, from a shortfall into a demonstrated decision. Two practical notes: test the run instructions on a clean checkout, since 'it works on my machine' is exactly what is being tested, and do not open with an apology.
Can you use AI to do a take-home assignment?
Use it the way you would use it in the job, be ready to explain every line, and follow the brief if it says anything about it. Most employers in 2026 have stopped pretending AI is not used and many now say explicitly that it is allowed, because banning it is unenforceable and testing for its absence measures nothing useful. Some ask you to disclose which parts you used it for, and if they ask, tell them accurately, since a mismatch discovered later reads as dishonesty rather than as a tooling choice. The real constraint is not policy, it is the follow-up conversation. Take-homes are almost always followed by a review call where someone asks why you structured it that way, what happens if the input doubles, and what you would change. Code you did not reason about collapses instantly under those questions, and it collapses in a way that is much worse for you than a smaller submission you fully understand would have been. So the honest rule is: generate whatever you like, then read it, understand it, cut what you cannot defend, and make sure the tradeoffs in your README are decisions you actually made.
What should you do if you never hear back after submitting a take-home assignment?
Follow up once at the date they gave you, or at ten days if they gave none, then treat it as closed and keep going. Silence after a submission is more common than after an interview and the reason is structural: there is no meeting on anyone's calendar forcing a decision, so your submission sits in a review queue behind live work. Send one short message that asks a specific question, because specific questions get answered: 'Are you still expecting to make a decision this week, and is there anything else useful I can send?' works better than a general check-in. If you get a rejection, do ask for feedback, and ask for one concrete thing rather than general thoughts, since 'was there a particular part of the submission that fell short?' occasionally gets a genuinely useful reply. If you get nothing at all after one follow-up, stop. It is worth naming plainly that being ghosted after an unpaid assignment is a real failure of process on the employer's side, and it is a legitimate reason to be less willing to spend unpaid hours on the next one.
How should employers design a take-home assignment?
Cap it at three hours, test the cap on your own team, and never send it before a human conversation. Eight rules cover almost all of it. Cap at three hours and verify it by having two of your own people do it timed, because candidates reliably take about twice as long as the author expected. Pay for anything beyond that cap. Put it after a real conversation, since an assignment as step one is the single biggest source of drop-off. Write the rubric before the first submission arrives, because a rubric written afterwards is a rationalisation. Use the same brief, cap and reviewers for everyone, which is what makes scores comparable and the process defensible. Have two reviewers score independently before they discuss. Use a toy problem and never a roadmap item, because if you could ship the output you have asked for free work whatever your intent. And give every submitter three sentences of real feedback. Then check completion rates by group: an unpaid multi-hour exercise selects for available free time, which is an adverse impact risk, and the first candidates to decline are always the ones holding competing offers.
Key takeaways
- A take-home assignment, or work sample test, is the only stage that measures output rather than the ability to talk about output. If you interview worse than you work, it is your best stage.
- Three hours is the ceiling for an unpaid exercise. Almost all the signal exists by hour two, while your cost keeps rising in a straight line.
- Assume the true cost is roughly double the stated estimate. Authors underestimate their own exercises because they already know the answer.
- Do it when it is capped, follows a human conversation, is a toy problem, and the scoring was explained. Negotiate at four to eight hours. Decline at ten-plus unpaid hours.
- The roadmap test settles most cases: if shipping your submission would save them a sprint, you are not being assessed, you are working.
- Negotiating is normal and usually works. Propose narrowing the scope, or offer a live session instead, and give them two easy yeses.
- Read the brief as evidence about them. Six things should be in it: a time cap, one narrow question, an out-of-scope list, the data, the evaluation criteria, and who decides by when.
- Send two clarifying questions within hours of receiving the brief. It is scored positively and it prevents the expensive rebuild.
- Write down what you are NOT going to do before you build. That single page is what stops three hours becoming eight.
- Complete and small beats broad and broken. One path that works end to end lets a reviewer extrapolate; four half-built ones let them conclude nothing.
- Reviewers open the README first, try to run it, and spend 10 to 20 minutes total. Spend your hours where their minutes actually go.
- Extra features beyond the brief count against you. Ignoring a written scope limit is the exact thing a good exercise is built to detect.
- 'What I left out, and why' is the highest-scoring paragraph you can write. It converts an unavoidable incompleteness into a visible decision.
- Stop at the cap and say what you cut. Never apologise for the submission, and never quietly overrun and hide it.
- With AI: use it as you would on the job, disclose it if asked, and cut anything you cannot defend, because the review call is where unexplained work collapses.
- Employers: cap at three hours and test the cap timed on your own team, pay above it, write the rubric first, two independent reviewers, never a roadmap item, and feedback for everyone.
- Employers: the first candidates to decline a long unpaid exercise are the ones with competing offers. The longer your assignment, the weaker your shortlist.
Frequently asked questions
What is a take-home assignment?
A take-home assignment is a small, realistic piece of work an employer asks you to complete on your own time, then submit for review. You will also see it called a work sample test, a take-home test, a take-home project, a take-home exercise, a coding challenge or a take-home case study, and while the artefact differs by field the format is identical: a brief, a time expectation, a deadline, and a submission that gets scored. It normally sits in the middle of a hiring process, after a recruiter screen and usually after a first conversation with the hiring manager, and it exists because it is the only stage that measures output rather than the ability to talk about output. That makes it genuinely good news for a lot of candidates, particularly people who interview worse than they work, career changers whose resume does not carry the story, and anyone whose strongest evidence is the thing they can build rather than the thing they can narrate. The problem is not the format. It is that the format has no natural limit, so a well-designed three-hour exercise and an unpaid twelve-hour project arrive in your inbox looking exactly the same.
How long should a take-home assignment take?
Three hours is the practical ceiling for an unpaid exercise, and most of what an employer can learn is already there by hour two. The reason is that the useful signals appear early: whether you understood the brief, whether you can scope, whether the thing runs, whether you can explain a tradeoff. None of those need six hours to demonstrate. What extra hours add is polish and breadth, which is exactly the part a reviewer skims. So the marginal information per hour collapses quickly while the cost to you keeps rising in a straight line. That asymmetry is the whole argument. Anything beyond three hours should either be paid or be replaced by a live session, and anything beyond about eight hours unpaid is not really an assessment at all: at that point the exercise mostly measures who had eight uncommitted hours available, which is a fact about someone's circumstances rather than their ability. One practical note if a brief gives no estimate at all: assume the true cost is roughly double whatever the author imagined, because assignment authors consistently underestimate their own exercises.
Should you do a take-home assignment?
Do it when the cap is three hours or less, it comes after you have spoken to a human, the task is a toy version of the work rather than a real deliverable, they told you how it is scored, and you genuinely want this specific job. Under those conditions it is the best stage in the whole process for you, because it is the one place where what you produce outweighs how well you interview. Negotiate first when the estimate is four to eight hours, the brief is vague, no evaluation criteria were given, or it arrives before any conversation. Negotiating is the move people forget exists: you can propose narrowing the scope to the core part, or offer a live session instead, and a reasonable employer will say yes. Decline when any single one of these is true: ten or more unpaid hours, the task is a live item on their roadmap, they will not tell you how it is evaluated, they want to keep or use the work regardless of outcome, or they are asking before a single human has spoken to you. The roadmap test is the clearest one. If shipping your submission would save them a sprint, you are not being assessed, you are working.
Should take-home assignments be paid?
Anything beyond about three hours should be paid, and paying for it is the clearest signal that an employer has thought about the exercise properly. The argument is not primarily moral, it is about what payment does to design. An employer who has to pay for six hours immediately asks whether they need six hours, and the answer is almost always no, so the assignment gets shorter and sharper. Payment also removes the selection effect that is the real problem with long unpaid exercises: an unpaid eight-hour task filters for people who have eight uncommitted hours, which quietly excludes candidates with caring responsibilities, a second job, or a current role with genuine demands, none of which correlate with being good at the work. As a candidate, it is entirely reasonable to ask, and asking well is easy: 'Happy to do this. Given the scope looks like a day rather than an afternoon, is this a paid exercise, or could we narrow it to the core part?' A company that reacts badly to that question has told you something useful for the price of one email.
Is a take-home assignment a good sign?
Usually yes, with one specific exception. Assignments are expensive for employers to set and to review, so a company that sends you one has generally decided you are a serious candidate rather than a maybe. It also almost always sits after the earlier filters, so reaching it means the resume screen and at least one conversation went your way. There is a second reason to be pleased: an assignment is the stage most likely to correct an unfair earlier impression, because it measures the work instead of the performance, which is why it tends to favour candidates who are stronger than their interviewing. The exception is when the assignment arrives as the very first step, before any human has spoken to you. That is not a signal of interest, it is a filter applied at volume, and it inverts the normal economics by making the candidate spend first. Treat a step-one assignment as a much weaker signal, and be correspondingly more willing to ask what the process looks like after it.
What if the take-home assignment takes longer than the stated time limit?
Stop at the limit, submit what you have, and say clearly what you cut. This is counterintuitive and it is genuinely the higher-scoring choice at any well-run company, because working to a stated constraint is one of the things the exercise is measuring. A submission that says 'I stopped at three hours as asked; here is what I deliberately left out and why' demonstrates scoping judgment, which is a senior trait, and it is the exact behaviour they want on the job when a deadline collides with an ambition. Quietly spending nine hours on a three-hour brief demonstrates the opposite, and it is more visible than people think: reviewers who set the cap have a good sense of what three hours produces. If you did overrun, be honest about it rather than hiding it, because being caught understating your hours is far worse than the overrun itself. The one thing not to do is apologise for the state of it. 'Sorry it is rough, I ran out of time' tells the reviewer how to read everything that follows, and they will oblige.
Can you ask clarifying questions about a take-home assignment?
Yes, and you should, in almost every case. Asking two sharp questions before you start is scored positively at most companies, for the same reason it is valued in the job: it is evidence that you spot ambiguity before you spend a day building the wrong thing. It also protects you, because the single most expensive mistake on a take-home is a confident answer to a question nobody asked. Send the questions early, ideally within a few hours of receiving the brief, so that waiting for a reply does not eat your deadline, and keep them to two or three that genuinely change what you would build. Good ones look like: is this optimising for accuracy or for speed of delivery? Should I assume the data is trustworthy or handle bad rows? Is this a prototype to be thrown away or the first version of something real? Bad ones are questions the brief already answers, or process questions like how long it should take when the brief has told you. If they refuse to answer or say to use your judgment, that is fine and it is also information: write your assumption down in the README and move on.
How do you politely decline a take-home assignment?
Decline the scope, not the process, and offer an alternative in the same message. Almost nobody is annoyed by a candidate who says no to twelve hours and yes to two. A version that works: 'Thank you for sending this over. I am interviewing with a couple of other companies at the moment and I am not able to commit ten unpaid hours to any single process. I would very happily do a two-hour version of the core problem, or a live ninety-minute session where you watch me work on it. Either is genuinely fine by me if one of them works for you.' That message is polite, specific, gives them two easy yeses, and does not lecture anybody. Send it promptly rather than sitting on the brief for a week, because a fast, clear no is respected while silence followed by a withdrawal is remembered. And accept that some companies will end the process there. That is a legitimate outcome and it is usually a good trade: a company that will not flex on ten unpaid hours at the interview stage is telling you something reliable about how it will treat your time later.
What do reviewers actually look at in a take-home assignment?
They open the README first, they try to run it, and they spend ten to twenty minutes total. That is the whole reality, and almost every mistake candidates make follows from not believing it. In practice the order is: read the README to understand what you did and why, attempt to run it exactly as documented, skim the structure of the work for clarity, look at one or two specific decisions in detail, and form a view. What that means is that the highest-return hour of your time is the one you spend writing up your assumptions, your tradeoffs and what you deliberately left out, because that is the part guaranteed to be read closely. And the lowest-return hours are the ones most people spend most heavily: visual polish, and features beyond what the brief asked for. Extra features are worse than neutral. When a brief says no styling and no authentication and you deliver both, you have not shown enthusiasm, you have shown that a written scope limit does not survive contact with you, which is precisely what a well-designed exercise is built to detect.
Should you go beyond what the take-home brief asks for?
No. Do exactly what was asked, do it well, and put everything else in a short 'what I would do next' section. This is the single most common way strong candidates lose a take-home, and it feels so much like diligence that it is hard to resist. The reasoning is simple: a brief with a scope limit is a test with two questions in it, one about the work and one about whether you can work to a constraint. Building the extra dashboard answers the first and fails the second. There is also a practical cost, because every extra feature is time not spent on the README, on making the thing run cleanly, or on the tradeoff paragraph that actually earns the interview. The productive version of the same instinct is to write it down: three lines saying what you would build next, in priority order, with a sentence on why, shows the same ambition and the same understanding of the problem, costs you five minutes instead of two hours, and reads as judgment rather than as scope creep.
What should the README for a take-home assignment include?
Six headings, and they take about thirty minutes to write. What this is: two sentences on what you built and what it does. How to run it: the exact commands, copy-pasteable, tested from a fresh clone rather than from your working directory. Assumptions I made: the ambiguities in the brief and which reading you chose, which converts every guess you made into a visible decision. Decisions and tradeoffs: three choices you faced, the alternative you rejected, and why, which is the clearest seniority signal available to you in the whole submission. What I left out, and why: the scope you deliberately cut, tied explicitly to the time cap. And with another day: three specific next steps in priority order. The fifth section is the one that changes outcomes, because it converts an incomplete submission, which every capped submission is, from a shortfall into a demonstrated decision. Two practical notes: test the run instructions on a clean checkout, since 'it works on my machine' is exactly what is being tested, and do not open with an apology.
Can you use AI to do a take-home assignment?
Use it the way you would use it in the job, be ready to explain every line, and follow the brief if it says anything about it. Most employers in 2026 have stopped pretending AI is not used and many now say explicitly that it is allowed, because banning it is unenforceable and testing for its absence measures nothing useful. Some ask you to disclose which parts you used it for, and if they ask, tell them accurately, since a mismatch discovered later reads as dishonesty rather than as a tooling choice. The real constraint is not policy, it is the follow-up conversation. Take-homes are almost always followed by a review call where someone asks why you structured it that way, what happens if the input doubles, and what you would change. Code you did not reason about collapses instantly under those questions, and it collapses in a way that is much worse for you than a smaller submission you fully understand would have been. So the honest rule is: generate whatever you like, then read it, understand it, cut what you cannot defend, and make sure the tradeoffs in your README are decisions you actually made.
What should you do if you never hear back after submitting a take-home assignment?
Follow up once at the date they gave you, or at ten days if they gave none, then treat it as closed and keep going. Silence after a submission is more common than after an interview and the reason is structural: there is no meeting on anyone's calendar forcing a decision, so your submission sits in a review queue behind live work. Send one short message that asks a specific question, because specific questions get answered: 'Are you still expecting to make a decision this week, and is there anything else useful I can send?' works better than a general check-in. If you get a rejection, do ask for feedback, and ask for one concrete thing rather than general thoughts, since 'was there a particular part of the submission that fell short?' occasionally gets a genuinely useful reply. If you get nothing at all after one follow-up, stop. It is worth naming plainly that being ghosted after an unpaid assignment is a real failure of process on the employer's side, and it is a legitimate reason to be less willing to spend unpaid hours on the next one.
How should employers design a take-home assignment?
Cap it at three hours, test the cap on your own team, and never send it before a human conversation. Eight rules cover almost all of it. Cap at three hours and verify it by having two of your own people do it timed, because candidates reliably take about twice as long as the author expected. Pay for anything beyond that cap. Put it after a real conversation, since an assignment as step one is the single biggest source of drop-off. Write the rubric before the first submission arrives, because a rubric written afterwards is a rationalisation. Use the same brief, cap and reviewers for everyone, which is what makes scores comparable and the process defensible. Have two reviewers score independently before they discuss. Use a toy problem and never a roadmap item, because if you could ship the output you have asked for free work whatever your intent. And give every submitter three sentences of real feedback. Then check completion rates by group: an unpaid multi-hour exercise selects for available free time, which is an adverse impact risk, and the first candidates to decline are always the ones holding competing offers.