How the interviews run

Think about a good car mechanic. You say: “The car makes a noise when I brake.” The mechanic does not read from a list of 50 questions. They ask: “Front or back?” Then: “Only when the car is cold, or always?” Then: “Since when?” Every question comes from your last answer. After a few minutes, they know where to look.

A serious technical interview works the same way. The interviewer listens first, then goes deeper into what you said, one step at a time, until they find the place where your knowledge stops. This page explains that pattern and the six interviews in Fennick’s process. After it, you are ready for Part 3, where five candidates go through the same ML deep dive.

The six interviews at Fennick

Fennick’s posting does not describe the process, so candidates learn it in the first call with the recruiter. Each interview checks something different, and a different person runs each one.

1. The recruiter call (30 minutes, Chantal Roy, Talent Partner). Chantal checks the basics: does your experience fit the level, what pay do you expect, when can you start, and can you explain your work to someone who is not an engineer. She also explains the process and the rules for each round. Chantal can answer questions about the process, the level and the pay. For questions about the daily work, such as which tools the team uses or how on-call works, she may say “Ask the team in the next rounds.” That is a normal answer. Write the question down and ask it later.

2. The hiring manager (45 minutes, Ravi Subramaniam, Engineering Manager). Ravi wants to know why you want this job, how you work with other people, and whether your past work matches the team’s problems. He asks about projects at a higher level than an engineer: what was the goal, what did you decide, what went wrong. He is also honest about the team’s weak points when you ask, and those answers tell you what your first months could look like.

3. Coding (60 minutes, one of the team’s ML engineers). This is practical Python and data work in a shared editor, not a puzzle. A typical task: here is a small table of orders. Clean it, then compute a feature such as “the store’s average preparation time over the last four weeks”. The interviewer watches whether you use only data from before each order. A feature that accidentally uses later orders is a small version of leakage, and it is easy to write by mistake. The posting asks for AI coding tools, but this round does not allow an AI assistant; the Python and pandas documentation is allowed. That is not a contradiction: the round checks what you can do and explain yourself.

4. The ML deep dive (60 minutes, video, Ioana Petrescu, Staff ML Engineer). This is the interview in Part 3. Ioana asks about a model that you put in production, or the closest thing that you have done, and goes deep into it. Then she gives you a real Fennick problem. She checks that your experience is real, how deep it goes, and how you think at the edge of what you know. No AI assistants in this round; paper notes are fine.

5. ML system design (60 minutes, Ben Adler, Principal Engineer). Ben asks you to design a complete system on a shared board, often the one that serves the delivery estimate at checkout. You talk through the parts: where the features come from, how the model is trained and released, what happens when a feature is late or missing, how fast it must answer, and how you know that it still works next month. In the middle, Ben usually changes one requirement, for example “Now we launch in a new city with no history.” He wants to see how your design changes, not a perfect first drawing.

6. The values conversation (45 minutes, Laura Fitzgerald, Director of Operations). Laura runs courier operations. She asks how you behave in difficult situations: when operations tells you the model is wrong, when your change makes things worse for couriers, when a deadline and quality conflict. She checks that you respect the people who live with the model’s numbers every day: couriers, store staff and support agents.

After the last interview, the interviewers meet in a debrief. Each one shares written notes, and together they decide. A strong result in one round does not cancel a serious concern from another one.

About the interviewer in Part 3

Ioana Petrescu has worked in machine learning for 11 years. She is from Romania and moved to Canada seven years ago. She built the ETA service. English is her second language. She speaks clearly and simply, and sometimes she stops to find a word. Two of the five candidates, Mateo and Hana, also speak English as a second language.

Watch how little this matters in the conversations. Ioana never judges grammar or accent. She listens for reasons, decisions and honesty. Your English does not need to be perfect; the interviewer listens for your thinking. We say more about this in our advice.

Other kinds of interview that you may meet

Other companies run ML engineer interviews differently. From candidate reports and preparation sites (not from the companies themselves), these are common:

• An algorithm coding screen: a classic programming problem, often before the main interviews. Many large companies still use it.
• ML coding from scratch: “Write logistic regression with only NumPy” or “Write k-means”. This checks that you understand what a library does for you.
• An ML fundamentals round: short questions about overfitting, regularisation, metrics and trees. A good one still grows from your answers.
• A take-home task: a dataset and a question, usually for a few hours of work, followed by a conversation about your choices. Most of the score comes from your reasons, not from the final number.
• An AI-assisted coding round: some companies now allow, or even require, an AI coding assistant, and watch how you use it and check it.

Rules differ from company to company, and from round to round. Ask the recruiter what is allowed in each round, and then follow the rules exactly. Some companies also record interviews and make an AI summary; they must tell you, and some let you say no. See our advice on why hidden AI help during an interview is a bad idea.

How a serious interviewer goes deeper

The ML deep dive starts with an open question: “Tell me about a model that you put in production.” Then the interviewer follows your answer. Here is how one sentence from a candidate can grow into twenty minutes of conversation.

Suppose a candidate says: “I built a churn model with XGBoost, and it had an AUC of 0.89.” (Churn means customers who stop using a product. AUC is a score for how well a model ranks positive cases above negative ones: 0.5 is random guessing, and 1 is perfect.) The interviewer goes down, level by level.

From one sentence to the edge

1. 1

   “How did you define churn? When exactly did the model make its prediction?”

   Is the target clear? A real model owner knows the exact definition and the moment of prediction.

2. 2

   “At that moment, which data did you really have?”

   Leakage. Features that are only known later make a model look much better than it is. 0.89 can be a warning sign, not only a good result.

3. 3

   “How did you split the data for testing? Why that way?”

   Does the candidate know that a model that will predict the future must be tested on a later period than it trained on?

4. 4

   “What did a simple baseline get? And why AUC, and not something closer to the business?”

   Did they make decisions, or follow a tutorial? Who used the score, and what did those people need from it?

5. 5

   “How was it used in production, and how did you know it still worked three months later?”

   Ownership after launch: serving, monitoring, drift, retraining. Many candidates stop having answers here.

6. 6

   “What would change if the team needed a score every time a customer opened the app?”

   The edge: from a batch model to a real-time one. The interviewer wants to see how the candidate reasons beyond their experience.

The interviewer plans the areas to probe, not the exact questions. The questions come from your answers. A candidate who says “We predicted on the first day of each month, from data up to the day before” gets a question about that day. A candidate who says “We used a random split” gets “Would that tell you how the model works next month?”

This is why lists of interview questions help so little. The questions come from your own work. What you can do is know your own work very well: every decision, every number, every failure.

The edge of what you know

Every candidate reaches an edge. A good interviewer goes there on purpose, because the most useful information is there. They want to see what you do when you do not know:

• Do you say clearly that you do not know, or do you talk around it?
• Do you reason from what you do know, step by step, out loud?
• Do you ask a question that makes the problem clearer?
• Do you stay calm and honest?

Here is a short example. The candidate set up drift monitoring with PSI (population stability index, a number that says how much the distribution of a feature has changed between two periods).

An example: reaching the edge

Ioana(interviewer):

You said the alert fires when PSI is above 0.2. Why 0.2?

Candidate(candidate):

Hmm. Honestly… it was the value in the article we followed. Many people use it.

Ioana(interviewer):

Okay. Was it a good value for your features?

Candidate(candidate):

I’m not sure. Let me think. What I know is, PSI compares two periods, bin by bin, and bigger means more different. But some features change every week anyway, like… payday, holidays. So for them 0.2 maybe fires too often. If I did it again, I would look at the old weeks first, see what is normal for each feature, and then choose.

Ioana(interviewer):

Mm-hm. Did it ever fire?

Candidate(candidate):

Yes, two times, I think. Once it was real, a field was empty after a change in the app. The other time it was a holiday week. So, a false alarm.

Why this works

The candidate does not pretend that 0.2 was a careful choice. They say where it came from, explain what PSI does, and reason to a better method out loud. Then they give a real example of a true alarm and a false one. Ioana learns more from this than from a perfect definition.

The Fennick problem

In the second half of the ML deep dive, Ioana gives every candidate the same problem. It is the real reason the team is hiring:

“Okay, now a real problem from our side. Customers see a delivery time in the app before they pay. At dinner time and when the weather is bad, our estimate is too optimistic. On normal days about 9% of orders arrive more than ten minutes late compared to the estimate; on those days it’s about 18%. People are angry, support tickets go up. How would you approach this?”

There is no single right answer. Ioana does not want a finished design in 20 minutes. She wants to see how you start: what you ask, what you would predict, how you would measure it, how you would test it with real customers, and what could break. Then she follows your answer, as she did with your project.

Ioana gives these facts when a candidate asks, or when the conversation reaches them:

• The current model is LightGBM (a gradient-boosted tree library) with about 120 features. It is retrained every week.
• The app calls the model on every checkout page view, about 1.5 million times a day. That is about 17 calls a second on average, and many more at dinner time. 99 of every 100 calls must come back in about 50 milliseconds or less.
• Features come from the feature store. Some are batch, such as the store’s average preparation time over the last four weeks. Some are real-time, such as courier locations and open orders at the store.
• Weather is not a feature yet.
• The team watches the error after delivery, but it does not watch the features themselves for changes.

Try it before you read the candidates

Take 20 minutes, and write or say out loud how you would approach the Fennick problem. Use what you learned from the posting and from Read it honestly. Answer these for yourself:

1. Should the app show one number or a range? What should “a good estimate” mean for the customer, and for Fennick?
2. Is a late order worse than an early one? How would you put that into the model or the metric?
3. Which new data would you add first, and how would you make sure it has the same value in training and in production?
4. How would you test a new model with real customers, when all customers share the same couriers?
5. After launch, how would you know that it still works next winter?

Keep your notes. When you read the five candidates, compare your answers with theirs. Each candidate starts from their own experience. That is normal, and you should do the same.

How to read the candidate pages

Each candidate page shows the same 60-minute ML deep dive with Ioana, as a conversation. Blue turns are the interviewer; green turns are the candidate. Between the turns, notes explain what is happening:

• What the interviewer is checking: the real question behind the question.
• How the interviewer goes deeper: why the next question follows from the answer.
• Why this works: what made an answer strong.
• Where this goes wrong: a weak moment, and why it is weak.
• A stronger answer: the same moment, answered better, in the candidate’s own words.
• Disagreeing well: how a candidate disagrees with the interviewer, with reasons.

The conversations are not perfect, because real conversations are not. People ask for a question again, lose their point, or need a minute to think. Each page ends with Ioana’s written notes, what happened next, and advice for readers with a similar profile.

The five candidates are:

1. The software engineer: Tunde has built fast, reliable services around a model, and is new to the decisions inside it.
2. The researcher: Anika has a PhD and deep modelling skill, and has never put a model in production.
3. The data scientist: Mateo built, deployed and monitored a credit model in Bogotá, and is new to real-time scale.
4. The platform engineer: Wei runs models in production every day, and has never had to choose what a model predicts.
5. The returner: Hana built ETA models before a three-year career break, and worries that the tools have changed.

Read them in any order. Start with the one that is most like you, and then read the one that is least like you.