In this article
Before you start
A take-home is one stage of the interview process and its loop stages. This page uses a machine learning (ML) brief as its example, but the structure fits any role.
Why interviewers ask this
The take-home assignment exists because a short live round shows how you talk, while a work sample shows what you hand over when nobody is watching. Employers who use one are advised to state a recommended time limit and to tell candidates not to exceed it. The same source recommends a 2-hour limit for nearly all roles and advises paying candidates when an assignment takes longer than 2 hours. A good submission is therefore judged partly on what you chose to do inside the limit.
A weak submission is a large pile of code with no explanation. A strong one is small, runs on the first try and says what it proves. After the submission, a review call often follows, similar to a project deep dive, so every choice must be defensible out loud.
A take-home assignment from first principles
- Take-home assignment
- A take-home assignment is a work sample that a hiring team sends you to complete on your own time, within a stated limit, and that is then scored against criteria, often before a live review.
- Scope note
- A scope note is a short section of your write-up that lists what you built, what you deliberately skipped and what you would do with more time.
In plain words
Think of a take-home as a cooking test. You cook at home and mail the dish. The judge cannot ask what you meant. So the plate and the note on it must speak for you. The analogy breaks in one place. A dish is eaten once. Your submission is reread and discussed later on a call.
In one precise sentence: a take-home submission is runnable, scoped work. It comes with the reasoning that lets a stranger trust it.
Because nobody is in the room, the reviewer has three questions and only your files to answer them. Does it run? Does it solve what the brief asked? Do the choices make sense? A short, clear README answers all three, which is why a small submission with a good note often reads better than a large one without. The reviewer may also be reading your work alongside many others, so make the first screen of the README carry the result.
Step 1: Read the brief and pin down the ask
Start by turning the brief into a checklist of deliverables, a deadline and a time limit. Write each as one line: what to build, what format to hand in, what the data or inputs are.
Here is an illustrative brief that belongs to no company: a table of 1,000 past orders, each labeled with whether the customer ordered again, and a request to predict repeat orders and explain how the team should use the result, within four hours.1 Input: the brief. Output: a checklist plus any questions you send the recruiter. If something is ambiguous, ask once, early, and write the assumption you made in your note. You now know exactly what is being asked, so the next step is to split your time.
Step 2: Budget the time and build the baseline first
Split the stated limit before you write code. In the illustrative four-hour plan, 20 minutes go to reading and planning, 60 to the baseline, 80 to one improvement, 40 to checks and error analysis and 40 to the write-up. The baseline and the first improvement take over half the four hours.1
The baseline comes first because it makes every later number meaningful. If 100 of the 1,000 illustrative orders are repeat orders, a model that always says "no repeat" scores 0.9 accuracy, so a model at 0.91 has barely improved on doing nothing.1 A held-out set is a part of the data kept out of training and used only to check the final model, and the baseline is scored on it too.
Text description of the diagram
- In the illustrative four-hour plan, 20 minutes go to reading and planning, 60 to the baseline, 80 to one improvement, 40 to checks and error analysis and 40 to the write-up.
- The baseline and the first improvement take over half the four hours.
Step 3: Write the scope note that names what you left out
The scope note is where most submissions lose points without anyone telling the candidate. Code that quietly skips something, such as class imbalance, a leaky feature or untested edge cases, reads as if you never noticed; the same gap named in the note reads as judgment.
A good note has three short lists: built, skipped on purpose with the reason, and next with more time. For the repeat-order example: "Built a majority-class baseline and one tree model scored on a held-out set. Skipped hyperparameter search because 40 minutes of the budget went to checks and error analysis. Next: check whether order date leaks the label." Keep the note in the README so it opens first.
Here is a complete illustrative README for the repeat-order brief. The model figure is illustrative; the baseline of 0.90 follows from the 100 repeat orders in 1,000.1
# Repeat-order prediction (illustrative example)
## Result
- Majority-class baseline accuracy on the held-out set: 0.90
- Tree model accuracy on the held-out set: 0.93 (illustrative)
- Errors cluster in first-time customers; see notebook section 3.
## How to run
pip install -r requirements.txt
python train.py --data data/orders.csv --seed 42
python evaluate.py --seed 42
## Scope note
- Built: majority-class baseline, one tree model, held-out evaluation.
- Skipped: hyperparameter search (40 minutes went to checks and error analysis).
- Next: check whether order date leaks the label; try class weights.
## Assumptions
- A repeat order means a second order within 90 days (my reading of the brief).Step 4: Run it fresh and submit
Before sending, clone your own repository into a new folder and follow your README from the top. Anything that fails on a clean copy will fail for the reviewer too.
Check that the data path, the install commands and the random seed are written down, that results in the note match what the code prints, and that the folder holds nothing you do not want read. Then submit inside the time limit, with a one-line message saying what is attached. If the brief allows or forbids AI tools, follow it exactly; the AI-assisted coding interview page explains how those rules are usually framed.
Step-by-step description
- Turn the brief into a checklist.
- Split the time, build the baseline first.
- Name what you left out.
- Clone, follow the steps, submit.
- A scope note lists what you built, what you skipped and what you would do next.
- Run the work from a fresh clone before you submit.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
Walk me through what a strong take-home submission contains.
I start by turning the brief into a checklist and a time budget, then I build the simplest baseline so every later number has something to beat. I add one improvement, check errors on a held-out set, and stop at the time limit. My README opens with a scope note: what I built, what I skipped and why, and what I would do next. Before sending, I clone the repository fresh and follow my own instructions. I would rather hand in a small result I can defend than a large one I cannot explain.
What makes it Staff-level is that it names the trade-off between depth and the time limit and treats the write-up as part of the deliverable.
The rubric
A rubric is a table of criteria with a description of each performance level, so every candidate is judged on the same things. Advice to employers is to use one for all candidates, and Google's re:Work site publishes a sample structured-interview grading rubric as an example of the format. The rows below are advice for what a strong answer shows, not any company's real scoring.
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | Code fails on a clean copy | Runs from the README and matches reported results | Adds checks that catch leakage and bad inputs |
| Depth | One model, no comparison | Baseline plus one justified improvement | Explains why the improvement helps, from error analysis |
| Trade-offs | None stated | Names skipped work | Ties each skip to the time budget and its risk |
| Communication | Raw code, no note | Clear README with a scope note | Opens with the result, the limits and the next step |
| Follow-up readiness | Cannot explain choices | Defends the main choices | Anticipates likely questions and answers with evidence |
Three variants of this question
What does an LLM evaluation take-home assignment look like?
A large language model (LLM) evaluation task usually asks you to measure how well a model answers some prompts. A strong submission defines the metric first, builds a small labeled test set, scores a simple baseline, and reports where the model fails with examples.
What does a data science take-home assignment need?
A data science take-home assignment needs a clear question, a baseline, a metric that fits the decision and an honest read of errors. The data science take-home tips that matter most are to state assumptions and to say what the result means for the business. Compared with a machine learning engineer brief, a data science brief tends to put more weight on the question and the interpretation, and less on packaging; read the brief for which it asks.
What changes in an AI agent or MLOps take-home?
An AI agent take-home adds tool calls and failure handling, so show a trace of one run and the cases where the agent loops or fails; the agent take-home page goes deeper. A machine learning operations (MLOps) take-home adds deployment and monitoring, so show how the model is packaged, tested and watched; see the MLOps take-home page. The scope note matters even more in both. For an AI engineer or full stack role with an AI brief, the same structure holds, and a reviewer can only judge what runs from your README.
Common mistakes
- "I built the most powerful model I could in the time." (wrong) That shows no baseline to compare against. (right) "I beat a simple baseline by a measured margin, and here is the margin."
- "I did not mention the data issue because it might look bad." (wrong) Silent gaps read as unnoticed. (right) "I found possible leakage, did not fix it in time, and flagged it in the scope note."
- "I spent eight hours because I wanted it to be perfect." (wrong) It ignores the stated limit, which is part of the test. (right) "I stopped at the limit and listed what I would add."
- "It works on my machine." (wrong) The reviewer cannot reproduce it. (right) "I ran it from a fresh clone and the
READMEsteps worked."
Follow-up questions
How do I approach a take-home assignment for a machine learning project?
Pin down the ask, build a baseline, add one improvement, check errors on a held-out set and write the scope note. The AI engineer interview questions page covers related questions for the role.
What is a take-home assignment in a machine learning engineer interview?
A take-home assignment in a machine learning engineer interview is a small project, often with data and a written explanation, sent before or between live rounds. How it is scored depends on the employer, so read the brief for the criteria.
How long should I spend on a take-home assignment?
Spend the time the brief states, and no more. RecruitingDaily recommends a 2-hour limit for nearly all roles and advises employers to pay candidates for assignments that take longer. The illustrative four-hour brief on this page is longer than that recommendation. The limit is part of what is compared across candidates, so stay inside it; if the limit is unclear, ask.
Can I use AI tools on a take-home assignment?
Follow the policy in the brief, and ask if it is silent. If tools are allowed, be ready to explain every line, because the review call tests that.
What happens after you submit a take-home assignment?
A review call or a written review often follows, where you walk through your choices. Practice explaining the baseline, the skipped work and the next step; the refactor take-home page and the forward deployed and applied AI engineer rounds page cover neighboring formats.
- A strong take-home submission is small, runs from a fresh clone and explains itself.
- Build a baseline first so every later number has meaning.
- Write a scope note that names what you built, skipped and would do next.
- Respect the stated time limit and the AI-tool policy in the brief.
Sources
- Navigating Take-Home Assignments for Effective and Equitable Hiring — RecruitingDaily, 26 Oct 2026
- Google's sample structured interview grading rubric (re:Work) — Google re:Work, 26 Oct 2026