In this article
Before you start
The take-home is one round of the interview process and loop stages.
Why interviewers ask this
Companies that run machine learning in production need people who can finish the hand-off from a trained model to a running service. Google's architecture guidance describes the common manual process: in it, data scientists hand a trained model as an artifact to engineers who deploy it (Google Cloud, accessed 2026-10-26). Many take-homes reported by candidates mirror that hand-off: you receive a model or data, then package, serve and check it.
A weak submission has a notebook with a good score and no way to run it elsewhere. A strong submission has a repository that builds from a clean machine, a service with a health route and a metrics route, a test that scores held-out data, and a readme that states results and limits. A Staff-level submission also records the decisions and what would change at production scale.
The MLOps take-home from first principles
- Container image
- A container image is a read-only package of an application, its libraries and its start command, built from a recipe file such as a
Dockerfile, that runs identically wherever a container engine runs it. Reviewers use it to run your work without matching your machine. - Monitoring endpoint
- A monitoring endpoint is a route on a running service that reports its health or its counters, such as request counts and error counts, so that a person or a tool can check the service without sending real predictions.
In plain words
Think of a restaurant recipe. A cook who makes one great dish at home has a result. A restaurant needs the written recipe and the same ingredients each time. It also needs a way to taste-check every plate. The analogy breaks in one place. A model can degrade silently as data changes, with no bad smell, so the checking has to be built in.
In one precise sentence, the MLOps take-home tests one skill. Can you make a model's training, serving and checking repeatable by someone else? Google's guidance says the level of automation of these steps defines the maturity of the machine learning (ML) process (Google Cloud, accessed 2026-10-26). A take-home is a small version of that automation.
Step-by-step description
- Read the brief and plan the time.
- Split before any preprocessing.
- Put the model in a container.
- Add monitoring, tests and a readme.
- Read the brief and plan the time first.
- Split the data before any preprocessing.
- Serve the model in a container.
- Add monitoring, tests and a readme.
Step 1: Read the brief and plan the time
The brief decides what is graded, so read it twice and write down every deliverable before writing code. Input: the brief, any provided model or data, and the stated time limit. Output: a checklist and a time plan.
Ask the recruiter about anything unclear, including whether AI tools are allowed; follow the stated rule. If the brief says to review the company's public code first, do that before designing. The table shows an illustrative four-hour plan.
| Block | Minutes (illustrative) |
|---|---|
| Read and plan | 20 |
| Baseline model | 40 |
| Serve and containerize | 90 |
| Tests and monitoring | 50 |
| Readme | 40 |
The blocks add up to 240 minutes (illustrative).1 You now have a plan whose first output, the checklist, feeds Step 2.
Step 2: Split the data before any preprocessing
The data split comes first, before scaling, imputing or choosing features. The scikit-learn documentation says to always split the data into train and test subsets first, particularly before any preprocessing steps (scikit-learn documentation source, accessed 2026-10-26). It also advises a pipeline. A pipeline is a single object that chains preprocessing and the model so each step is fitted on the right rows only.
The cost of skipping this is large. In a demonstration of 100 rows and 2,000 random features with random labels, choosing the 20 best-looking features on all rows gives a mean test accuracy of 0.866; choosing them on the training rows only gives 0.496, which is chance.1 The model learned nothing in both cases, and only the second number says so.
Text description of the diagram
- Selecting features on all rows gives a mean test accuracy of 0.866.
- Selecting features on training rows only gives 0.496, which is chance.
Input: raw data. Output: a split and a pipeline. Say the split rule in your readme, so the reviewer sees it.
Step 3: Serve the model in a container
The service wraps the model in an API and the container makes it portable. Input: the trained model file, for example a .pt checkpoint. Output: a container image that starts with one command and answers prediction requests.
Keep it plain: load the model once at startup, validate the request shape, return the prediction and a clear error when input is bad. Pin dependency versions and put the start command in the Dockerfile. Weight size matters for image size. Bidirectional Encoder Representations from Transformers (BERT)-base (Bidirectional Encoder Representations from Transformers) has about 110 million parameters (Devlin et al., 2018), which is 440 MB in 32-bit numbers and 220 MB in 16-bit numbers.1
If the brief names tools, use them, such as FastAPI for the service. A model registry is a store that versions models and their stages, and MLflow is one example. Output of this step feeds Step 4.
Step 4: Add monitoring, tests and a readme
Monitoring and documentation turn a demo into engineering. Input: the running service. Output: a health route, a metrics route, a test and a readme.
Add a /health route that reports the service is ready, and a /metrics route with request counts, error counts and response times. Add a script that scores the model on a new evaluation file.
Monitoring a model also means watching the data, not only the service. Log summary statistics of the input features and the distribution of predictions, and compare them with the training data to catch drift, a slow change in what the model sees. Check the serving input schema against the training schema to catch training-serving skew, a difference between the features seen in training and those supplied in production. Google's level-0 description notes that engineers who deploy the model need to make the required features available in production for low-latency serving, which can lead to training-serving skew (Google Cloud, accessed 2026-10-26).
Then write the readme: how to build, how to run, the result, the split rule, the limits and what you would do next. Google's guidance defines level 1 by automating the training pipeline for continuous training (Google Cloud, accessed 2026-10-26); a one-command retrain script shows that direction.
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
You get a trained model and a day to deploy it. What do you do?
I treat it as a small production hand-off, not a modeling contest. I read the brief and list what is graded. I split the data before any preprocessing and keep every fit inside one pipeline, so no test information leaks into training. I put the model behind an API with a health route and a metrics route, log prediction and input distributions for drift, pin dependencies and build a container that starts with one command. I add a test that scores held-out data, and a readme with results, limits and next steps. If time runs out, I cut features, never the tests or the readme.
What makes it Staff-level: it names a leakage control, a serving contract and a cut rule, and it frames the work as a hand-off someone else must run.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Correctness | Score from a leaky split | Split first, fit on train only | Pipeline plus a leakage check in a test |
| Reproducibility | Runs only in a notebook | Container builds from clean machine | Pinned versions and a one-command retrain |
| Serving and monitoring | No health or metrics route | Health and metrics routes | Drift check on inputs and predictions, alerts, input validation and a rollback note |
| Communication | No readme | Readme with run steps and results | Decision log and limits at production scale |
| Follow-up readiness | Cannot explain choices | Explains each trade-off | Names what changes with ten times the traffic |
Three variants of this question
Containerize a model and test it on a new evaluation dataset
Reported by candidates for a Tempus AI task. Build the image, load the model at startup and write a script that reads the new file, scores it and prints the metric and the data shape it expected, so a schema mismatch fails loudly.
Deploy a provided BERT sentiment checkpoint with a monitoring endpoint
Reported by candidates as a cross-company task. BERT checkpoints are large, so state the image size, load once at startup, and expose health and metrics routes.
Train, register in MLflow, serve with FastAPI and add a web interface
Reported by candidates for a Thoughtworks task. Log the run and register the model first, load it from the registry in the service, and keep the web interface thin: it only calls the API.
Common mistakes
- "I scaled the data, then split it." (wrong) The scaler saw test rows, which is data leakage. (right) "I split first and fitted the scaler inside a pipeline on training rows only."
- "Accuracy is the headline." (wrong) The assignment tests delivery, and a score without a repeatable build proves little. (right) "Here is the score and the one command that reproduces it."
- "It works on my machine." (wrong) The reviewer cannot run it. (right) "The container image builds from a clean checkout and I tested that."
- "No readme, the code is clear." (wrong) A reviewer needs the run steps and the limits. (right) "The readme lists build, run, results, limits and next steps."
Follow-up questions
How do you present a ML take home?
Lead with a readme that gives the result, the exact commands to build and run, the split rule and the limits, then offer a short walkthrough of the decisions. A worked job interview take-home assignment example shows the same structure for other roles. If a call follows, rehearse a two-minute tour; the AI engineer interview questions show what neighboring rounds ask.
Are take home assignments still used?
Yes: Anthropic publishes its original performance take-home (Anthropic, GitHub, accessed 2026-10-26), so the format has been used at AI labs. Its README says the repository holds a version of the task "before Claude Opus 4.5 started doing better than humans given only 2 hours". Formats vary: time-capped, paid, or replaced by live pairing, so ask the recruiter. For AI engineer roles, see the retrieval-augmented generation (RAG) take-home and the agent take-home.
Is the Anthropic performance take-home an MLOps test?
No. The original performance take-home (Anthropic, GitHub, accessed 2026-10-26) is a task of optimizing code for a simulated machine, judged on cycle count, with files such as perf_takehome.py, problem.py and watch_trace. It is a performance task, not a deployment task, so nothing in it asks you to package, serve or monitor a model. The Anthropic interview process page covers the wider loop.
What do you do if the time runs out?
Cut features, never the tests or the readme, and state in the readme what is missing and why. If AI tools are allowed, say how you used them; the AI-assisted coding interview page covers how such rounds are graded.
- The MLOps take-home tests whether someone else can rebuild, run and check your model.
- Split the data before any preprocessing and keep fits inside a pipeline.
- Ship a container with health and metrics routes, a held-out test and a readme.
- Write the limits down; honesty about gaps beats a hidden shortcut.
Sources
- MLOps: Continuous delivery and automation pipelines in machine learning — Google Cloud Architecture Center (accessed 2026-10-26), 26 Oct 2026
- Common pitfalls and recommended practices (data leakage) — scikit-learn documentation source (accessed 2026-10-26), 26 Oct 2026
- Anthropic's original performance take-home (README) — Anthropic, GitHub (accessed 2026-10-26), 26 Oct 2026
- BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding (arXiv 1810.04805) — arXiv (Devlin et al.), 11 Oct 2018
