Imagine that a neighbour sends you a message: “Can you help me on Saturday? I need someone strong, with a car, who is good with furniture.” Before you say yes, you ask a few questions. What are we moving? How many floors? Is there a lift? Often the real answer is simple: there is one heavy sofa, and it does not fit through the door. “Strong, with a car, good with furniture” was the neighbour’s guess at the help they need. The sofa is the real problem.
A job description works in the same way. It is a team’s guess at the person who can solve their problem. The list of skills is the “strong, with a car” part. Before you ask “Do I have these skills?”, find the sofa: what problem does this team have? When you know that, you can see which lines matter, which lines are only words, and what to ask.
The posting below is for a company that does not exist. We built it from 13 real Machine Learning Engineer postings at banks, fintech companies, delivery and ride companies, and an online marketplace. We kept their real patterns: the clear parts, the vague parts, and the small problems that real postings have. Then we put everything in one company, so that the whole guide can use the same team and the same problem.
Fennick delivers groceries and pharmacy items in Canada on the same day. It has about 600 people, a head office in Toronto, and works in 14 cities. On a normal day, customers place about 85,000 orders. A courier picks up each order from a partner store and brings it to the customer’s door.
Before a customer pays, the app shows them a delivery time: “Arrives in about 35 min”. That number comes from a machine learning model. The Delivery Intelligence team owns this model and a few others. It is a small team: five ML engineers, two data scientists, a product manager and an engineering manager. This posting is for one more ML engineer.
Fennick brings groceries and pharmacy essentials to your door the same day, in 14 Canadian cities. We are a customer-obsessed, data-driven team that moves fast and owns outcomes. Every day, our models help hundreds of thousands of people plan dinner, pick up a prescription, or get diapers before bedtime.
Delivery Intelligence builds the models behind our delivery promise: the delivery-time estimate (ETA) that customers see in the app, the demand forecasts that plan courier supply, and more. As a Machine Learning Engineer, you will own the full ML lifecycle, from problem framing to data, training, deployment, monitoring and retraining. You will help us improve the accuracy of our delivery promises, especially at peak times.
This posting is for an existing vacancy. Canadian work experience is not required. We use AI tools to help screen applications; a person reviews every application before any decision. If you need an accommodation at any stage of the process, tell our recruiting team.
Composite job description for a fictional company, built from 13 real Machine Learning Engineer postings.
Before you compare the posting with your CV, answer three questions about it. Write your answers down. It takes about ten minutes. Then compare them with ours below.
What problem does the team have? Write it in one sentence, with no tool names.
Who sees what the model produces, and what happens to them when it is wrong? Think of more than one group of people.
Find two lines that do not fit together. A good posting tells one story. Where does this one tell two?
Our answers
1. The problem. Customers see a delivery time before they pay, and at busy times that time is not reliable enough. Fennick needs someone to make the estimate better and to keep it good as conditions change. The clue is one short phrase: “improve the accuracy of our delivery promises, especially at peak times”. That is the sofa. Almost everything else in the posting is a way to move it.
2. The people, and the cost of a mistake. There are at least three groups.
Customers see the estimate. If it says 35 minutes and the order arrives in 60, the customer is angry, writes to support, and may ask for a refund. Some of them are waiting for medicine, not only for dinner.
Support and operations staff deal with the angry messages, and they plan couriers from the demand forecast.
Fennick’s business loses in a quieter way when the estimate is too long. A customer who sees “90 minutes” may close the app and order somewhere else.
So a mistake costs money in both directions, but not the same amount. Late hurts more than early, and “always say a longer time” is not a solution either. The posting says nothing about this trade-off. It is a sign that the interviews will ask about it.
3. Two lines that do not fit. There are a few. Here are the ones that we noticed first.
Gradient boosting, but deep experience in PyTorch or TensorFlow. Delivery-time and demand models usually learn from tables: one row per order, with columns such as store, distance, time of day and number of open orders. For this kind of data, gradient-boosted trees (for example LightGBM or XGBoost) are a common, strong choice. So why is “deep experience” in a deep learning framework required?
“A bias for simplicity”, next to a list of nine MLOps tools. No team of five engineers uses Kubeflow, Airflow, SageMaker, Feast and Tecton together. The list is longer than the work.
“Own the full ML lifecycle”, but no word about data quality, on-call or what happens when the model is wrong. If you own the whole life of a model, these are a big part of the job.
If your answers are different, that is fine. The habit is what matters: start from the problem and the people, then look at the tools. In the interviews, the conversation will be about the delivery estimate, the customers and the data. Tools come up only as ways to solve that.
Look for the interview process in the posting. It is not there. In the 13 real postings that we studied, not one described its interview stages. This is normal, and it is not a bad sign. It means that you ask the recruiter in the first call. We describe Fennick’s six stages in How the interviews run.
On the next page, we read the posting line by line. We say honestly what is really required, what is only a wish, and what is missing. We also say who should apply, and which questions to ask at each stage.
