Interviews · 7 min read

Take-home assignments: what they're grading, and when to say no

Take-home assignments have quietly become the middle of many hiring processes, particularly at startups and for data, engineering and design roles. They are also the stage candidates resent most, because they are the only part of an interview that consumes an entire weekend and frequently arrives with no indication of how it will be judged.

Handled well they are an advantage, because most submissions are mediocre in predictable ways. Handled badly they are a large amount of unpaid work for a rejection with no feedback. The difference is mostly about understanding what is being graded.

What is actually being assessed

Almost never raw correctness. The problems are usually underspecified on purpose, and the interesting signal is what you do about that. Reviewers are reading for how you scoped an ambiguous brief, what you chose not to build, whether your work is legible to someone who was not in your head, and whether you can explain your decisions afterwards.

This is why a technically perfect submission with no explanation often loses to a smaller one that states its assumptions. The first proves you can code or analyse. The second proves you can be worked with — and the reviewer already assumed you could do the technical part, or you would not have reached this stage.

The file that decides it

Include a short README, or a few paragraphs of notes if it is not a code assignment. Say what you understood the problem to be, what you deliberately left out and why, what you would do with another day, and where you think it is weakest. Ten sentences is enough.

This is the single highest-return thing you can do, and a minority of candidates do it. It converts every omission from a mistake into a decision. A missing test suite reads as sloppiness on its own; the same gap with a line saying you prioritised the data-integrity path over coverage given the time box reads as judgement. Reviewers are trying to find evidence of judgement and it is usually the scarcest thing in the pile.

How long to spend

Respect the stated time box, and say what you did. If they said four hours, spend four hours and note what you would have added with more. Candidates routinely spend fifteen hours on a four-hour brief, which distorts the comparison for everyone and tells the reviewer you either cannot estimate or cannot stop — neither is a quality anyone is hiring for.

If the brief has no time box, ask for one. That question alone is a small positive signal, and it protects you from the version of this that eats a week.

When it crosses into unpaid work

There is a real line, and it is worth naming rather than pretending every assignment is fine. A synthetic problem, sized in hours, that produces nothing the company can use is a legitimate assessment. A brief that asks you to solve a live problem from their actual roadmap, or to produce deliverable work on their real data, is asking you to work for free — and it happens often enough to watch for.

The tells are specific: the task maps suspiciously precisely onto something in their product, you are asked to work on their real data or their real codebase, the scope would take a week, or you are asked for strategy documents rather than a work sample. It is reasonable to reply asking whether they would consider paying for the time, or to propose a scoped-down version, or to offer a live working session instead. Some companies pay for take-homes as standard, which is a good sign about how they treat people generally.

Declining does not have to end the process. A polite note saying the scope looks closer to a paid engagement, with an offer to do a shorter exercise or walk through comparable past work, is a professional response. If that ends the conversation, you have learned something useful cheaply.

Practical things that raise the score

Make it runnable. If a reviewer has to fight your setup, that is the first impression. Pin your dependencies, write the exact commands, and try them on a clean checkout — the number of submissions that fail on the reviewer's machine is high, and it is entirely avoidable.

Handle one edge case well rather than gesturing at ten. Name things clearly, because naming is the cheapest legibility you can buy. Commit in logical steps if it is a repository, since the history is readable evidence of how you work. And if you used AI to write parts of it, be ready to explain every line — a follow-up conversation is standard now, and being unable to defend your own submission is worse than not using AI at all.

Then prepare to discuss it

There is usually a review call, and it carries more weight than the artefact. Reread your submission beforehand, because a fortnight can pass and having to reconstruct your own reasoning live is a bad look. Expect the reviewer to push at the weakest part — that is not a trap, it is the actual question, and you flagged that part yourself in the README, which is why the README is worth writing.

Have the answers to three things ready: why you scoped it this way, what you would change with more time, and what you would do differently at ten times the scale. Those are asked almost every time.

The honest summary

A take-home is worth doing when it is time-boxed, synthetic, and part of a process you otherwise want. It is worth pushing back on when it is open-ended, uses their real work, or arrives before anyone has spent thirty minutes talking to you. Spend the stated time, write the notes, make it run, and be ready to defend it. Most of the pile will not have done those four things.

If you use AI, use it the way you would at work

Most companies now assume AI assistance and many say so explicitly. The ones that care are usually not trying to catch you out; they want to know whether you can direct it and check its output. That is a real skill and it is increasingly the thing being assessed.

The rule that keeps you safe is simple: do not submit anything you cannot explain line by line. The review conversation will find the gap immediately, and being unable to defend your own submission is worse than a smaller piece of work you understand completely. If the brief asks you to disclose AI use, disclose it plainly and say what you used it for and what you changed — that answer usually reads well.

When you get no feedback

It is common and it is the most demoralising part. If a submission is rejected with nothing attached, it is reasonable to ask once, briefly, for anything they can share. Some will, most will not, and the reason is usually policy rather than rudeness.

What you can do instead is build your own feedback loop. Keep the assignment. A fortnight later, reread it as a reviewer would and note what you would change now — the distance makes weaknesses obvious that were invisible at the time. Take-homes accumulate: the third one is materially better than the first if you keep them and revisit them, and most candidates delete them and start from scratch each time.

Ask whether there is an alternative

If you have public work — a repository, a portfolio, published writing, a talk — it is worth asking whether that could substitute, particularly if you are employed and time-constrained. Some companies will accept a walkthrough of existing work instead, which is faster for both sides and often more informative, because real work carries the constraints that a synthetic exercise strips out.

The framing that works is cooperative rather than resistant: you are happy to do the exercise, and you also have something directly comparable you could walk them through if that would be more useful. The worst outcome is they say no and you do the assignment anyway.

The version of this that is worth doing eagerly

It is easy to read all of the above as a warning, so it is worth saying the other half plainly. A good take-home is one of the fairest assessment formats there is, and for some candidates it is the best possible stage of the process.

If you interview badly under time pressure, if English is not your first language and live rounds disadvantage you, if you are self-taught and your credentials do not open doors, or if your best work is simply not visible on a resume, a take-home is where you get to be judged on what you actually produce. Whiteboard rounds reward a fairly narrow kind of performance. A work sample rewards the thing the job consists of.

So the position worth holding is not that take-homes are exploitative, it is that scope is what separates a fair assessment from unpaid labour. Time-boxed, synthetic, and reviewed by someone who will discuss it with you: do it properly and treat it as an opportunity. Open-ended, on their real problems, before anyone has spoken to you: push back. The difference is not hard to see once you know to look.

Related guides

Try JobStraight free →