Prepare for your own interview

You have now watched five people go through the same ML deep dive. Their experience was very different, but the strong moments had the same causes. The candidate knew one model in detail, from the target to what broke after launch. They connected every decision to a real cost: a late order, an angry customer, a courier waiting at a store. They said clearly what they did not know, and they reasoned from what they did know.

Think about a driving test. Reading the rules helps, but people pass because they drove the real roads many times, with someone next to them who said “check your mirror”. The test still feels different, but you know what to do. This page is a plan for that kind of practice. It takes about three weeks of short sessions.

Step 1: Choose one posting, and read it properly

Do not prepare for “ML engineer interviews” in general. Prepare for one real posting, then adapt for the next one. Read it in the way that you saw on The job description and Read it honestly:

• Find the problem behind it, in one sentence.
• Find out who uses the model’s output, and what a mistake costs them.
• Sort the lines into required, wish and missing.
• Make the preparation table.

The table shows you the stories that you already have, and the gaps that you must either close or explain honestly.

Step 2: Choose one model, and write drill-down notes for it

In every ML engineer loop, someone asks about a model that you put in production. Choose one model, the one that you know best. If you did not own it alone, that is fine. Be clear about which parts were yours.

For that model, write short answers to these questions. Use real numbers where you have them, and approximate numbers where you do not (“around 200 features, I think”).

1. The target: what exactly did the model predict, and why that and not something else?
2. The moment of prediction: when did the model run, and which data was really available at that moment?
3. The split: how did you test it? If the data changes over time, did you test on a later period?
4. The baseline: what did a simple rule or a simple model get? How much better was yours?
5. The metric: why that metric? Who used the output, and what did a mistake cost them?
6. Serving: batch or real-time? How fast? What happened when a feature was missing?
7. After launch: how did you know that it still worked? What did you watch?
8. What broke: the worst problem after launch, how you found it, and what you changed.
9. The edge: what would change with ten times more traffic, a strict time limit, or a new market with no history?

Questions 2 and 8 matter more than most people think. Question 2 is where leakage hides. Question 8 is where interviewers learn that you really did the work, because only the person who fixed a problem remembers it in that much detail.

If you cannot answer question 3, 4 or 7 for your model, go back to it now. Ask a colleague who knows. Rebuild the test on a later period. Compute the baseline. You saw in The software engineer and The platform engineer what happens when someone worked near a model but never had to answer these questions.

If you have no model in production

Build a small one that behaves like a real one, and make the decisions yourself. It does not need to be big. It needs to be honest. A good shape for a project:

• Data that changes over time, for example hourly bike rentals, taxi trips or energy use.
• A test on a later period, and a simple baseline to beat.
• A prediction of a range, not only one number, for example the 10th and 90th percentiles.
• A small API that serves the model, with a measured response time.
• One monitoring check that compares new data with the training data.

Hana’s project in The returner followed this shape. Our case study Forecast bike-share demand covers the first steps, and Serve a house-price model shows how to put a model behind an API. Read our advice too.

Step 3: Practise the opening out loud

The deep dive starts with “Tell me about a model that you put in production”. Your first two minutes decide where the conversation goes, because the interviewer asks about what you say. So say the things that you want to be asked about.

Prepare a two-minute walkthrough. It should touch:

• the problem, and who used the model’s output;
• the target and one important decision, with the reason;
• the result, in numbers, compared with the baseline;
• one thing that went wrong after launch.

Say it out loud, and record it on your phone. Listen once. Most people talk too much about tools (“we used Airflow, MLflow, Kubernetes…”) and too little about decisions. If you speak English as a second language, do not try to memorise perfect sentences. Practise the order of your ideas, and let the words be simple. Our lesson Explain decisions shows this step in detail.

Step 4: Practise the basic decisions that every round checks

In the five interviews, the same few ideas came back again and again, in different words. Every serious ML engineer loop checks them, in the deep dive, in system design, and sometimes in coding. For each one, practise saying the idea in two or three plain sentences, with an example from your own work if you have one.

The idea	A question that checks it	Where to practise
Leakage, and testing on a later period	“Your model looks very good offline. What would you check first?”	Train, validation and test sets
Turning a business need into a target	“What exactly should the model predict for this?”	Translate a need
A metric that matches the cost of mistakes	“Late is worse than early. How does your metric show that?”	Regression metrics
Predicting a range, not only one number	“How would you show a range? How do you check that the range is honest?”	Estimate house prices
Errors by group, not only on average	“The model is fine on average. Where is it bad?”	Slice analysis
The same feature in training and in production	“Good offline, worse online. Where do you look?”	Package artifacts
Watching the model after launch, and retraining	“How would you know it is still working next month?”	Plan production checks
Testing with real customers when they share resources	“Customers share couriers. How do you run the test?”	The Fennick candidate pages, especially The data scientist and The returner
When a simple model is enough	“Why not a neural network?”	When a simple model is better

You do not need to be an expert in all nine. You need to recognise each one when it appears in a question, and to say something correct and honest about it.

Step 5: Practise the company’s problem

Most ML deep dives and system design rounds use a problem from the company’s own work. You can usually guess it from the posting. Fennick’s posting said “improve the accuracy of our delivery promises, especially at peak times”. So a delivery-time problem at busy times was not a surprise.

Write the problem that you expect, in two or three sentences, as Ioana did. Then answer it out loud for 20 minutes, with a timer. Before you finish, check that you touched these points:

• What should the model predict, and what does the customer or user see?
• How do you measure “good”, and is one kind of mistake worse than the other?
• Which data would you add, and can you get the same value in production?
• How do you test it on a later period, and then with real users?
• How fast must it answer, and what happens when a feature is missing?
• How do you know that it still works in three months?
• Who outside engineering do you talk to first?

Do this two or three times, on different days. Each time you will find a gap that you can read about before the next try.

Step 6: Prepare for the other rounds

The deep dive is one round of six. Do not forget the others.

• Coding: practise practical pandas and SQL on real-looking data: joins, group-by, time windows, and missing values. Practise features that look back in time without using future rows. If the company also uses an algorithm screen, practise some classic problems too. Ask the recruiter which kind it is.
• System design: practise drawing a full system in a fixed order. Start with the goal and the label. Then the features and the model. Then the offline test, serving and the online test. End with monitoring and retraining. Then ask a friend to change one requirement in the middle, as Ben does. The order helps you not forget a part. It is not a script to recite.
• Values: prepare two or three real stories. One where someone outside engineering told you that your work was wrong. One where you chose quality over a deadline, or the other way, and why. One where your change hurt someone, and what you did.

Step 7: Get interviewed by a person

Practice alone cannot surprise you. Ask a friend or former colleague, ideally an engineer or data scientist, to interview you for 45 minutes. Give them your CV and the nine questions from step 2, and ask them to go deeper on whatever you say. Afterwards, ask for one strength and two things to improve.

Then change places and interview them. As the interviewer, you will hear quickly how a general answer sounds, and how much a specific one helps.

You can also practise with an AI assistant. Ask it to play a strict interviewer who follows up on your answers and never accepts a general answer. This is good practice. Using AI during a real interview is something very different, and we ask you never to do it (our advice).

Step 8: Prepare for the edge

You will reach the edge of your knowledge in every good interview. Prepare for it like any other part.

Write down three topics from the posting where you expect to reach your edge. For an ML engineer, they are often online experiments, real-time features, or a model type that you have not used. For each topic, write what you do know and how you would find out the rest. Then practise saying it: “I haven’t used that directly. What I know is… If I had to decide today, I would start by…”

Also prepare for the other kind of edge: when the interviewer says something that you think is wrong. You saw Anika gently correct Ioana about quantile loss in The researcher. Know your main topics well enough to explain your view with a reason, politely, and to accept a good counter-argument. See our advice on disagreeing.

Step 9: Prepare your questions

Write two or three questions for each interview stage, from your preparation table and from Read it honestly. For an ML engineer role, the most useful questions are about the model’s daily life:

• How are new models released?
• How does retraining run, and who understands it?
• Which features break most often?
• How often are you on call?

These questions show that you think like someone who will own the model. They also give you the information that you need to decide.

On the day

• Ask at the start what is allowed: notes, documentation, an AI assistant. Rules can be different in each round. Then follow them exactly.
• For a video interview, test your camera, microphone and screen sharing the day before.
• It is normal to say “Let me think for a moment” and then think in silence for 20 or 30 seconds. It is also normal to ask for a question again, or to ask what a word means.
• Keep paper and a pen near you. A quick drawing of the data flow often helps you think.
• Treat the interviewer as a future colleague. You are also finding out whether you want to work with them.

After the interview

Write down every hard question on the same day, while you still remember it. Then practise those questions. If you were not chosen, ask politely for feedback. Not every company gives it, but some do, and one honest sentence can save you weeks.

Some of the result is outside your control (our advice). In this guide, Mateo, a strong second choice, got a call three months later when a second position opened. Tunde was referred to another team, and that team hired him. Keep in touch with people you meet, keep building, and keep your plan focused on the roles that you want.

A three-week plan

The plan below summarises the steps. It assumes about one hour on most days, next to a job, family or other studies.

Week	Main work	Out loud
1	Read the posting and make the preparation table. Write drill-down notes for one model. Fill the gaps in questions 3, 4 and 7.	Record the two-minute walkthrough twice.
2	Go through the nine basic decisions in step 4. Prepare your three edge topics, your values stories and your questions. Practise pandas and SQL for coding.	Answer the company’s problem twice, with a timer.
3	Read your notes again. Fix what the practice showed you. Practise one system design with a changed requirement.	One mock interview with a person, then one more after you fix what they said.

Then apply, and keep the notes. The next posting will need only a few changes.