Read it honestly

On the previous page, you found the problem behind the posting: the delivery time in the Fennick app is not reliable enough at busy times, and the team needs someone to make it better and keep it good. Now we read the posting line by line, as an experienced ML engineer would before applying. We put every line in one of three groups:

• Really required: the team cannot hire someone without it, and the interviews will test it.
• A wish: the team would like it, but the job does not depend on it. Long lists feel safer to the people who write postings, so wishes get added.
• Missing: the posting does not say it, but the job clearly needs it. These lines are often the most important, because the interviews ask about them and many candidates do not prepare.

Our reading is a careful guess, not a fact, so we also give the questions that turn guesses into answers.

The level and the pay

The posting does not name a level. You have to read it from the other lines. “4+ years building and shipping ML systems in production” and “own the full ML lifecycle” describe an intermediate to senior engineer. That is someone who can take a vague problem (“the estimate is bad at dinner time”), turn it into a model, put the model in production, and keep it healthy, with some help but without step-by-step direction. Nothing asks you to lead people or set the direction for other teams.

The pay is CAD 135,000 to 170,000, plus a bonus and equity. That is close to the real Canadian postings that we read. Ask where in the range offers usually start; some companies start most new people near the bottom.

The “Good to know” section exists because of Ontario law. Since 1 January 2026, a public job posting in Ontario (for employers with 25 or more employees) must include the expected pay, must say if AI is used to screen applicants, must say if the vacancy exists now, and must not require Canadian work experience. So if your experience is from Bogotá, Lagos or Warsaw, it counts in the same way as experience from Toronto. In other provinces and countries the rules are different, and you may need to ask about pay yourself.

What is really required

Under the long lists, the job needs five things. The interviews will spend most of their time on them.

1. You have owned a model in production. “Owned” is the important word. It means that you were responsible for what the model predicts, not only for the machine that runs it. You chose the target, or at least understood why it was chosen. You knew how good it was, and you noticed when it got worse. Read “4+ years” as: you can talk about one real model for 20 minutes, including what went wrong after launch. If you can, the number of years matters less than it looks.

2. You can make good decisions with tabular data. Most of this job is rows and columns: orders, stores, couriers, times. The interviews will check the basic decisions that every tabular model needs:

• What exactly do we predict? For a delivery estimate, is it one number, or a range?
• What data do we have at the moment of the prediction, and what do we only learn later? Using later data by mistake is called leakage, and it makes a model look better than it is.
• How do we split the data for testing? For anything that changes over time, you train on the past and test on a later period. A random split mixes the future into the training data.
• Which metric matches the real cost of a mistake?

The posting says only “solid understanding of machine learning”. In the interviews, this line turns into many questions.

3. You can serve a model fast and safely. “Low-latency model serving” is in the posting with no number. Think about where the estimate appears: on the checkout page, every time someone opens it. So the model must answer in a few tens of milliseconds, many times a second, all day. You need to know what makes a prediction slow (often reading the features, not the model), and how to release a new model without breaking checkout.

4. You can keep a model healthy after launch. The posting says “monitor models in production”. Behind those words is a big topic. Data changes: new stores open, the weather changes, a feature pipeline breaks quietly. You need to know what to watch, when to retrain, and how to notice a problem before customers do.

5. You can work with people who run the real operation. The posting lists operations last, but at a delivery company it matters a lot. Operations staff plan couriers, talk to stores and hear from angry customers. They often know why the estimate was wrong last Friday before the data shows it. You must ask them good questions and explain trade-offs without jargon.

What is probably a wish

The degree. “MS or PhD preferred” is a wish. The same posting accepts “4+ years” of work instead of a PhD. Strong production work counts more than a degree for this team. If you have a PhD and no production work, the degree does not replace production experience either. We come back to this in The researcher.

PyTorch or TensorFlow, “deep experience”. You saw this on the previous page. The products in the posting are delivery times and demand forecasts on tabular data. For that, gradient-boosted trees are the usual first choice, and often the last one too. Expect a question like “Why would you choose a tree model here, and when would a neural network be worth it?” more than a question about PyTorch details. If you have not used PyTorch, say so, and talk about the models that you have used.

The long tool list. Kubeflow, Airflow, MLflow, SageMaker, Feast, Tecton, Docker, Kubernetes, Terraform. A small team uses a few of these, not all. What the team really wants is: you have deployed models with some tools of this kind, you understand what each kind of tool does, and you can learn their own setup. Ask the recruiter which tools the team uses today. Do not try to learn nine tools in a week.

Spark, Ray or Dask. At about 85,000 orders a day, one year of history is around 31 million rows. That is large, but often fine for one big machine with careful code. It is probably not the center of the job.

LLMs and generative AI. About half of the real postings we read had a line like this. It rarely decides who gets hired for an ML engineer role. Expect one question, such as “Where could an LLM help this team, and where not?” A calm, honest answer is enough.

AI coding tools. This line was rare in 2024; in 2026 some postings require it. Read it as “we expect you to work well with modern tools, and to check what they write”. It does not tell you what is allowed in the interviews, so ask.

What is missing, and matters

Data quality and training/serving skew. The posting never says “data quality”. But a model with many features from batch tables and real-time streams has many places to go wrong. One common problem is training/serving skew: a feature is computed one way for the training data and another way in production. The model looks good in testing and is worse with real customers, and nobody sees why. For this team, assume that data quality is a large part of the job.

How the model is tested with real customers. “Design and run experiments (A/B tests)” sounds simple. At a delivery company, it is not. Customers in the test group and the control group share the same couriers and stores, so a change for one group can affect the other. This is called interference. You do not need to know every method for it, but “I would split users 50/50” is not a full answer here.

On-call. Not mentioned, as in almost all the real postings. But if the model service breaks on a Friday evening, someone must fix it. Ask how often you would be on call, and what usually goes wrong.

Scale and speed. The posting says “low-latency” and “scalable”, with no numbers. How many predictions a day? What is the time limit for one prediction? Ask. The answers change the design a lot.

What the platform already does. Is there a platform team that runs training and deployment? How does retraining run today, and how many people understand it? The answers tell you how much of your week goes to modelling, and how much to keeping the machines running.

Words that describe the culture

Some words in the posting describe the culture, not the work: “customer-obsessed”, “data-driven”, “moves fast”, “owns outcomes”, “a bias for simplicity”. These can mean trust, and work that reaches customers quickly. They can also mean that the team is too small, or that “own” means “you are alone with it”.

“A bias for simplicity” is the most useful of these words. It tells you that a simple model that works, with clear reasons, is a good answer in the interviews. Believe that line more than the tool list.

To learn the real culture, ask: “Tell me about the last time a model change went wrong. What happened next?” A healthy team answers with a real example and without blame.

Who should apply

Nobody matches every line of this posting, and nobody expects it. Use the five requirements above, not the full list. In Part 3, you follow one candidate for each situation below.

• You are a backend engineer who has built the systems around a model, such as training jobs, serving and caching: apply. You are strong in requirement 3. Prepare requirement 2 carefully, because it will be your gap. See The software engineer.
• You have a PhD or research experience, and no production work: apply if the production side interests you, and be honest about it. Practise simple models and latency, not only the newest methods. See The researcher.
• You are a data scientist who has deployed a model and watched it in production: apply. You may be closer to this job than your title suggests. Prepare for real-time serving and online tests. See The data scientist.
• You are a platform or MLOps engineer who deploys models that other people design: this role asks for decisions about the model itself. If you can explain why a model and a metric were chosen, apply. If you cannot yet, prepare that first, or look for ML platform roles. See The platform engineer.
• You worked as an ML engineer before a career break, and you have refreshed your skills: apply. Your fundamentals still count, and a gap in your CV is not something to apologise for. See The returner.

Turn the posting into a preparation plan

Now connect each requirement to what the interviewers will probably ask and to the evidence that you can show. The table covers the five requirements and two of the missing items.

From the posting	What they will probably ask	Evidence that you need
Owned a model in production	“Tell me about a model you put in production. What happened after launch?”	One model that you can explain for 20 minutes: target, data, split, metric, serving, what broke
Decisions with tabular data	“Why that target? How did you split the data? Why that metric?”	Clear reasons for each decision, and one mistake that you found, such as leakage
Fast, safe serving	“The page calls the model on every view. How do you keep it fast? How do you release a new version?”	A service you built or worked on, with its real response times
Healthy after launch	“How did you know it still worked a month later? What did you watch?”	A monitoring check that you set up, and one alert or problem that it found
Work with operations	“Operations says the estimates are wrong on Fridays. What do you do?”	A story where people outside engineering changed your model
Data quality and skew (missing)	“The model is good offline and worse in production. Where do you look?”	A way to compare training features with production features
Online tests (missing)	“How would you test a new model with real customers here?”	A basic A/B test design, and an idea of what can go wrong in a marketplace

If you cannot fill the right-hand column for a row, that is your preparation for the next weeks. Our lesson Prepare for applications shows the same method for any posting.

Questions to ask the team

An interview goes in both directions (our advice). These questions turn our guesses into facts. Ask each one where it fits best. Fennick has six stages; we describe them on the next page.

• Recruiter (Chantal Roy): “What are the interview stages, and is an AI assistant allowed in any of them?” “Which tools does the team use today?” “Is there on-call for this role, and how often?” “Where in the range do offers usually start?”
• Hiring manager (Ravi Subramaniam): “What would I work on in my first three months?” “How does the team decide that a new model is good enough to release?” “How does retraining run today, and who understands it?”
• Coding interview: “Is this close to the code that the team writes every day?” “Which libraries can I use?”
• ML deep dive (Ioana Petrescu): “What was the hardest production problem with the ETA model so far?” “Which features do you trust least?”
• System design (Ben Adler): “What is the latency limit for the estimate today, and where does the time go?” “What is the next big change in the platform?”
• Values conversation (Laura Fitzgerald): “When the estimate is wrong, how do operations and the model team find out, and who decides what to change?”

Listen to how people answer. A clear answer with an example is a good sign. A vague answer to a simple question is also information.

Your turn: read a posting that you want

Find a real ML engineer posting for a role that you want. Then do these four things.

1. Write the problem behind it in one sentence, with no tool names.
2. Sort its lines into the three groups: really required, a wish, missing.
3. Find the line that shows what the model’s output is used for. If you cannot find one, that is your first question for the recruiter.
4. Make the preparation table for the main requirements, and write one question for each interview stage.

If you cannot decide whether a line is required or a wish, write it as a question for the recruiter. That is a normal question to ask, and the answer helps you prepare.

What happens next

On the next page, we look at Fennick’s six interview stages: who runs each one, what each one checks, and how a serious interviewer moves from what you say to the edge of what you know.