The email arrives on a Thursday. There is a dataset attached, a loose set of instructions, and a line at the bottom that says "this should take about three hours."
It will not take three hours. It never does. And the candidates who spend fourteen hours on it do not reliably beat the ones who spend four.
Take-home assignments have become standard at a lot of companies, partly because they test something a conversation cannot. But most candidates approach them the wrong way, treating them as an endurance test instead of what they actually are: a sample of how you work when nobody is watching.
What reviewers are actually looking for
Ask a hiring manager how they grade a take-home and you will rarely hear "completeness" at the top of the list. What comes up instead is judgment.
Did the candidate figure out what mattered? Did they make reasonable assumptions when the brief was ambiguous, and say so? Can someone else read this in ten minutes and understand the decisions behind it?
A polished half-solution with clear reasoning usually beats a sprawling full solution with none. Reviewers are imagining what it would be like to receive your work in a real project, and a real project always has more scope than time.
Scope it before you start
Read the brief twice, then write down three things before touching the work:
- What is the single question this assignment is asking me to answer?
- What is explicitly required versus what is merely suggested?
- What am I choosing not to do, and why?
That third one is the difference-maker. Most briefs are deliberately larger than the stated time budget, because how you cut scope is part of the test.
If the brief says three hours, plan for four and hard-stop at five. Set a timer. When it goes off, you switch from building to writing up.
Ask questions before you begin, not after
Candidates hesitate to ask clarifying questions because they worry it looks like they cannot figure it out. The opposite is usually true.
One well-aimed email is a positive signal. Something like: "Before I start, I want to confirm the priority. Should I optimize for accuracy of the model or for a clear explanation of the approach? I have limited time and would rather do one well."
Send it once, keep it short, and start working on reasonable assumptions if you do not hear back. Do not wait for a reply you may not get.
Write the summary first
Before you build anything, draft the summary you want to hand in. Two or three sentences: what you did, what you found, what you would do next with more time.
Writing it first forces you to decide what the deliverable actually is. It also stops you from wandering into a technically interesting side path that nobody asked about.
You will revise it at the end, and that is fine. The point is to work backwards from the output instead of forwards from the data.
What to cut when you run out of time
You will run out of time. Here is a rough order for what to sacrifice:
Cut first: styling, extra visualizations, alternative approaches you explored, edge cases that are unlikely in practice.
Cut second: breadth. One question answered well is stronger than four answered shallowly.
Do not cut: the write-up, your assumptions, and a clear note about what is unfinished. These cost fifteen minutes and carry more weight than another hour of building.
An assignment that says "I stopped here because of the time limit, and here is what I would build next" reads as disciplined. An assignment that quietly trails off reads as incomplete.
The write-up is the assignment
Most candidates treat the write-up as packaging. Reviewers treat it as the main event, because it is the only part that shows the reasoning behind the work.
Keep it short and structured:
- The question you answered. One sentence.
- Your approach. A short paragraph, not a tutorial.
- Assumptions you made. Bullet them. This is where judgment becomes visible.
- What you found. The actual answer, stated plainly.
- What you would do with more time. Two or three specific items, not vague ambitions.
Aim for one page. If your write-up is longer than the reviewer wants to read, you have already lost some of its value.
Small things that make a disproportionate difference
Name your files something a stranger can understand. A folder of files called final_v2_actual is a small red flag about how you would behave on a team.
Make it runnable. If there is code, include the exact commands to run it and the versions you used. Reviewers who cannot reproduce your work often stop trying.
Proofread. Careless typos in a document you had days to prepare say something you do not want said.
Deliver on time, or ask for an extension before the deadline rather than after. Both are fine; silence is not.
When to decline
Not every take-home deserves your weekend. A reasonable assignment is scoped to a few hours, is clearly a simulation rather than real company work, and comes after at least one conversation with a human.
If you are handed a twelve-hour project before anyone has spoken with you, it is fair to ask whether the scope can be reduced or whether there is an alternative, such as a live working session. Companies that care about candidate experience will often say yes.
The mindset that works
Treat the assignment as a work sample, not an exam. Exams reward completeness. Work samples reward the ability to deliver something useful under real constraints.
Do the thing that matters, explain why you did it, be honest about what you left out, and hand it in on time. That combination beats brute force more often than most candidates expect.