Read it honestly

On the previous page, you found the decisions behind the posting: Parlo’s product managers change the app all the time, and they need someone who can tell them, with evidence, what works and how sure we are. Now we read the posting line by line, as an experienced data scientist would before applying. We sort every line into 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 collect there.
• 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 list the questions that check it.

First: which kind of Data Scientist job is this?

Imagine that three people tell you, “I am a doctor.” One works in an emergency room, one is a family doctor, and one does research in a laboratory. Same title, very different days. “Data Scientist” in 2026 is the same, so first find out which kind of job the title hides. In real postings, we found five common kinds:

• Product analytics or decision science. Metrics, funnels, A/B tests, product managers, dashboards. Interviews: SQL, product sense, experiment cases.
• Experimentation or causal inference specialist. Hard experiment problems: users who affect each other, synthetic control, power, variance reduction. Usually senior or staff level.
• Machine learning or algorithms. Models in production, thresholds, optimisation, or “Algorithms” in the title. Interviews: ML and Python coding.
• Metrics or analytics engineering. Pipelines, data quality, trusted definitions. Often no experiments at all.
• AI enablement or LLM evaluation (new in 2026). LLMs, prompts, evaluation of generated queries or answers, agents.

Two tips help. First, the words after the comma in the title (“Growth”, “Ads”, “Algorithms”, “Causal Inference”) often tell you more than “Data Scientist” itself. Second, look at the verbs in “What you will do”. The verbs show you the work. The tool list does not.

So what is the Parlo job? “Growth & Learning”, A/B tests across onboarding and subscriptions, metrics, recommendations to product managers: this is mainly a product analytics and experimentation job. Two lines pull in other directions. “Build machine learning models to predict churn” is a line from the ML kind. “Measure success for new AI-powered features” touches the new LLM-evaluation kind. Our reading is that most of the work is experiments and product analysis, a small part is modelling, and the AI feature is the reason they are hiring now. You can check this with one question to the recruiter: “In the last six months, what did the data scientists on this team spend most of their time on?”

The level and the pay

“3+ years of experience” and “own analyses end to end” describe an intermediate data scientist. That means someone who can take a vague question from a product manager and bring back a clear answer, without step-by-step direction. Nothing asks you to manage people or set standards for the team. Those words (“mentor”, “set best practice”, “influence senior leadership”) appear in senior and staff postings.

The pay range is CAD 115,000 to 145,000, plus a bonus and equity. The range is in the posting because, in Ontario, a public job posting must now include the expected pay. Since 1 January 2026, Ontario postings must also say if AI is used to screen applicants, say if the vacancy exists now, and must not require Canadian work experience. That is why the “Good to know” section exists. In other provinces and countries, the rules are different, and you may need to ask for the range 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. SQL that you can trust and explain. SQL was in every real posting we read, and every analysis at Parlo starts with a query. The important word is trust. A query can run without errors and still give the wrong number, for example when a join repeats rows, or when users with no activity disappear from the result. The posting also says “use AI tools to increase the speed and quality of your work”. Put these two lines together: the team expects that you may use an AI assistant to write SQL, and that you can check and explain every line it writes.

2. Experiments, and the statistics under them. An A/B test is like a fair comparison between two groups of plants: you give the new fertiliser to some plants chosen at random, not to the plants that already look healthy, and then you compare. Designing and analysing these tests means more than reading a results page. Expect questions such as: How many users do you need? How long must the test run? What does the confidence interval tell you, and what does it not tell you? What happens if you look at the results every day and stop when they look good?

3. Choosing the right metric. “Define the metrics for your product area” is a short line with a lot inside. For a language app, is a good day one where the learner opens the app, finishes a lesson, talks with the AI tutor, or learns something? Each choice leads to a different decision. The interviews will ask you to choose, and to say what each choice misses.

4. Clear recommendations to people who do not do statistics. “Turn analyses into clear recommendations” is in every posting, so it is easy to skip. Do not skip it. The product manager needs to know what to do this week, how sure you are, and what would change your mind. They do not need your method.

5. Using AI tools, and checking them. This line is new. About half of the postings we read now ask for it. Read it in two parts. “Increase the speed” means: they expect you to use an AI assistant for SQL, code and first drafts. “And quality” means: you must catch its mistakes. A data scientist who pastes AI-written SQL without checking it is a risk, and the interviews are designed to find out which kind of user you are.

What is probably a wish

Machine learning. “Build machine learning models to predict churn” is in the duties, and scikit-learn, XGBoost and PyTorch are in the requirements. But the rest of the posting is about experiments, metrics and decisions. A churn model can be useful, but it does not tell the product manager whether a feature causes learners to stay. Expect the interviews to care more about “Is this effect real?” than about “Which model is best?” If you know ML well, it helps. If you do not, it will probably not decide the result.

The tool list. Snowflake and BigQuery are two warehouses that do the same job. Looker, Tableau, Mode and Hex are four tools that partly do the same job. The team uses one or two of each kind. Know SQL well and one reporting tool, and ask the recruiter which ones the team really uses.

“PhD a plus”. A PhD helps if it gave you deep training in statistics or causal inference, and many teams count it as two to four years of experience. It does not replace product sense or speed. If you do not have one, ignore this line.

Causal inference (partly). The posting names it, but it does not explain it. Causal inference means finding out what caused a change, not only what happened at the same time. An A/B test is the simplest causal method; other methods, such as difference-in-differences, work on data that you only observe. Our guess: the team needs you to understand why a simple before-and-after comparison can lie, and to know when a better method is needed. So prepare the ideas well, even if you skip the advanced methods.

What is missing, and matters

How much time goes to dashboards and small requests. The duties never say “dashboards”, but the tool list has four reporting tools. In most product data teams, reports and quick questions (“Can you pull the numbers for the Spanish course?”) take a large part of the week. Ask how much. It changes your daily life more than most lines.

How alone you will be. “DRI for data in your product area” sounds like trust. It may also mean that you are the only data scientist next to a product manager, with nobody nearby to check your work. Ask who reviews an analysis before it reaches a decision.

How Parlo measures learning. The team is called Growth & Learning, and the company promises that learners “make real progress”. But there is no line about how progress is measured. Measuring use is easy; measuring learning is hard. This is probably a gap at the company too, and a very good topic for your questions.

How experiments are run. Who decides when a test is finished? Are some features released without a test? The answers tell you how much of your work will be careful experiments, and how much will be cleaning up after launches that had no plan.

The interview process. Only one real posting in ten that we read described its interviews. Ask in the first call, especially about the AI rules for each round.

Words that describe the culture

Some words are about the culture, not the work: “data-driven”, “AI-first”, “DRI”, “own end to end”, “growth mindset”, “passion for languages”. They can mean that your analysis really changes decisions. They can also mean that people want data to confirm a decision that is already made. You cannot tell which from the posting, so ask questions that people can answer with an example: “Tell me about a time an analysis changed a product decision here.” “Tell me about a time a result was not what the product manager wanted. What happened?” A healthy team answers these easily.

Who should apply

Nobody matches every line, and the people who wrote it do not expect it. Use the five requirements above, not the full list:

• You are a product analyst with strong SQL and real A/B tests, and you want more say in decisions: apply. Prepare the statistics under your tests, because that is where the interviews will push.
• You have a PhD or research background in causal inference, but no product job: apply. Your rigour is rare. Prepare to be fast and simple, because a product manager needs an answer this week, not a study next quarter.
• You come from teaching or another field close to language learning, and you have trained in data: apply, but know that this posting asks for more statistics than most career changers have. Your domain knowledge is worth more here than the posting shows.
• You are an ML data scientist who builds strong models: apply, but be ready for a job that is mostly about decisions and experiments. Ask early if the company has a more ML-focused team.
• You are a senior data scientist looking for work at a lower level: apply, and expect the team to ask kindly whether you will stay. Have an honest answer.

In Part 3 of this guide, you follow five candidates, one for each of these situations. Each one goes through the same product case.

Turn the posting into a preparation plan

Now connect each requirement to the probable questions and to the evidence that you can show.

From the posting	What they will probably ask	Evidence that you need
SQL you can trust	“Write the retention query. Why is this a LEFT JOIN? How do you know the number is right?”	Comfort with joins, dates and window functions, and a habit of checking results
Experiments and statistics	“How long would this test need to run? What does this interval mean?”	One test you designed or analysed, explained in plain words
Choosing metrics	“What is the main metric here? What could go wrong if we use it?”	A story where the metric choice changed the decision
Clear recommendations	“What would you tell the product manager on Friday?”	A two-minute summary of one past analysis, with how sure you were
AI tools, checked	“The assistant wrote this query. Walk me through it.”	Practice explaining and testing AI-written SQL
Measuring learning (missing)	“How would you know that people learn more?”	A few honest ideas, and good questions
Before-and-after traps (missing)	“Usage went up after the launch. Did the launch cause it?”	Simple examples of season, novelty and selection effects

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). The questions below turn our guesses into facts. Ask each one in the interview where it fits best.

• Recruiter call: “What are the interview steps, and what are the AI rules for each one?” “Which warehouse and reporting tool does the team use?” “In the last six months, what did the data scientists spend most of their time on?”
• SQL and analysis screen: “How much of the week goes to reports and quick requests?” “Who reviews an analysis before it goes to a product manager?”
• Product case: “How do you decide when an experiment is finished?” “Are some features released without a test? Who decides?” “How does Parlo know if learners learn more?”
• Take-home presentation: “What would a first project look like for the person in this role?” “How do you work with the learning-design team?”
• Values conversation with a product manager: “Tell me about a time an analysis said something you did not want to hear. What did you do?” “How do you and the data scientist decide together when you disagree?”

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 Data Scientist posting for a role that you want. First, decide which of the five kinds of job it is. Look at the words after the comma in the title, and at the verbs in the duties. Then sort its lines into the three groups: really required, a wish, missing. Write the decisions behind the posting in one sentence. Make the preparation table for its 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 the five interviews in Parlo’s process: 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.