Skip to content
jobs·jobs·jobs.com

Take-Home Assignments and Work Samples: How Much Time to Give

A take-home assignment tests how you work when nobody is watching, which is most of a remote job. Here is how to scope the time, what reviewers actually grade, and when an assignment is asking for too much.


· 7 min read

A flat illustration of a document with a checklist beside a timer dial whose first third is highlighted in yellow.

A take-home assignment is the closest thing in a hiring process to the job itself: you get a problem, some ambiguity, a deadline and no one looking over your shoulder. Remote employers lean on it for exactly that reason. The candidates who do well are rarely the ones who spend the most hours. They are the ones who scope the work, make their thinking visible and hand in something a reviewer can evaluate in fifteen minutes.

What the employer is trying to learn

A live interview shows how you think under pressure with someone prompting you. A take-home shows something different, and for remote work more relevant:

  • Whether you can work from a written brief. Most remote work starts as a ticket, a doc or a message, not a conversation.
  • How you handle ambiguity. Every brief has gaps. Reviewers watch whether you ask, assume silently, or assume and say so.
  • Your judgment about scope. What you chose not to do tells them as much as what you did.
  • How you communicate the result. The note that accompanies your submission is part of the test, even when nobody says so. It is a direct sample of your asynchronous communication.

Keep that list in view while you work. An assignment that is technically strong but arrives as a zip file with no explanation fails three of the four.

How much time is reasonable

Employers usually state an expected effort. Treat that number as a budget, not as a floor. A team that says "about three hours" has calibrated its rubric to three hours of work; a submission that obviously took fifteen does not score five times higher, and it signals that you either cannot estimate or cannot stop.

Typical formats and what a sensible time box looks like:

Format Common in Reasonable effort
Small coding exercise or bug fix Engineering 2–4 hours
Data set with questions to answer Data, analytics 3–4 hours
Product or design critique, short spec Product, design 2–4 hours
Writing sample, campaign brief, mock email Marketing, support, sales 1–3 hours
Mock discovery call or account plan Sales, customer success 1–2 hours of prep
Multi-day project or paid trial Senior roles, small companies Should be paid

These are ranges from practice, not rules. The useful test is proportionality: the effort should match the stage. Two hours before a first conversation with a human is a lot to ask. Four hours as the last step before an offer is ordinary.

If no time estimate is given, ask for one. "How long do candidates usually spend on this?" is a normal question and the answer tells you what depth they expect.

Before you start: four questions worth asking

Read the brief twice, then send one short message with your questions. Asking is not a weakness; on a remote team, a person who clarifies up front saves everyone a week. Good questions:

  1. What will you evaluate? Some teams share the rubric. If they care about tests and you spend your time on a polished interface, you have answered the wrong question well.
  2. Who reviews it, and what happens next? A debrief call where you walk through your decisions is the best version of this format. If there is one, you can leave trade-offs for discussion instead of solving everything.
  3. What is the deadline, and is it flexible? Most teams will give a few extra days to someone with a full-time job or caregiving duties. Ask early, not the night before.
  4. Are there constraints on tools? Language, framework, slide format, and whether AI assistants are allowed. Policies differ widely as of late 2026: some employers forbid them, some expect them and ask you to describe how you used them. Do not guess. If you use an assistant where it is permitted, say so in your note and be ready to explain every line in the debrief.

If the recruiter cannot answer and does not offer to find out, note that. It is a small data point about how the company runs, and it belongs with the rest of your research on the employer.

Doing the work inside the time box

Plan the hours before you open an editor or a slide deck. A split that works for most formats:

  • First 15 percent: plan. Restate the problem in your own words. List the requirements, rank them, and decide what you will cut if time runs short.
  • Middle 60 percent: build the core. Get one complete path working end to end before polishing anything. A finished small thing beats an impressive half.
  • Next 15 percent: verify. Run it from a clean state. Follow your own setup instructions. Reread the brief and check each requirement off.
  • Last 10 percent: write the note.

People skip the last step when time is tight, and it is the one with the highest return.

The submission note

Whatever the role, include a short document, a README for code, a cover page for a deck or analysis. One page is enough:

  • What you built or concluded, in three sentences.
  • Assumptions you made where the brief was silent. "I assumed the export is run nightly, so I optimized for clarity over speed."
  • Trade-offs and what you left out, with reasons. "No authentication, since the brief focused on the data model."
  • What you would do with another day. This shows you see the gaps and saves the reviewer from wondering.
  • How to run or read it, tested on a clean machine or by someone who has not seen it.
  • Time spent, honestly. If you went over, say by how much and why.

A reviewer with six submissions to grade will read this page first and form most of an opinion from it.

What makes a submission stand out

Not volume. Reviewers see plenty of submissions that add features nobody asked for. The ones that get discussed in the hiring meeting tend to share a few traits:

  • They answer the question that was asked. Every stated requirement is met or explicitly declined with a reason.
  • They are easy to review. Clear structure, sensible names, one command to run, charts with labeled axes, a summary on top.
  • They show one moment of real judgment. A data analyst who notices that a tenth of the rows are duplicates and says how that changes the answer. A software engineer who writes three tests for the edge cases that matter instead of thirty for the trivial ones. A product designer who explains which user problem the brief underspecified and how they resolved it.
  • They are honest about limits. "This breaks if the file exceeds memory; here is how I would fix it" reads as senior. Hiding it reads as not having noticed.

When the assignment asks too much

Most take-homes are fair. Some are not, and you are allowed to notice.

Scope creep. "Build a production-ready app" or "prepare a full go-to-market plan" for an unpaid exercise is out of proportion. A reasonable reply: "I can give this about four hours. In that time I would focus on X and Y and outline Z. Does that work for the evaluation?" Good teams say yes. A team that insists on twenty unpaid hours is showing you how it treats people's time.

Real work for free. An exercise built on a generic or fictional scenario is a test. A request to fix the company's actual bug, write copy for its actual launch or produce a strategy for its actual client is work. Larger assignments of that kind should be paid, and some employers do pay a flat fee for longer exercises. It is fair to ask whether the work will be used and who owns it. If nothing is signed, do not assume you have given your rights away, but do not assume you can publish it either. Ask before putting a take-home in a public portfolio.

Assignments that are not interviews at all. A "test task" that arrives before you have spoken to anyone, comes through a chat app, or involves buying equipment, handling money or handing over account credentials is a known scam pattern. Check the posting against the red flags for remote job scams before you spend an evening on it.

Declining is also an option. If you are in late stages with two other companies and a fourth asks for a weekend, a polite "I am withdrawing because I cannot give this the time it deserves" costs you nothing and keeps the door open.

The debrief

Many processes follow the take-home with a call where you present it. Prepare for three kinds of questions: why you chose this approach over the obvious alternative, what you would change at ten times the scale, and where the weakest part is. Name the weak part yourself before they find it. Bring the same evidence-first habit you would bring to any other remote interview question, and check your screen-sharing setup beforehand, since fumbling with windows eats the time you need for substance. The video interview setup guide covers that part.

What to do next

Before your next process reaches this stage, prepare the parts that do not depend on the brief:

  1. Write a reusable template for the submission note with the six headings above.
  2. Set up a clean starting point for your format: an empty project that runs, a slide master, a notebook with your usual imports.
  3. Decide your personal ceiling, the number of unpaid hours you will give at each stage, so you are not deciding under deadline pressure.
  4. When the assignment arrives, send your clarifying questions the same day, block the time on your calendar and stop when the box is full.

Keep reading