Prepare for your own interview

You have now watched five people go through the same product case. They had very different backgrounds, but the strong moments had the same causes. The candidate asked questions before they gave answers. They knew one past analysis in detail. They explained statistics in plain words. And they gave the product manager a clear recommendation, together with how sure they were.

Think of learning to drive. You can read the rules in a book, but the test checks whether you look in the mirror at the right moment, without thinking about it. Interviews for data scientists are similar. Most candidates know what a confidence interval is. Fewer say “compared with what?” by habit, in the first minute of a case. That habit comes from practice. This page is a plan for that practice. It takes about three weeks of short sessions.

Step 1: Choose one posting, and find out which kind of job it is

Do not prepare for “Data Scientist interviews” in general. The title covers very different jobs. Choose one real posting, and decide first which kind it is: product analytics, experimentation specialist, machine learning, metrics and data quality, or AI evaluation. Read it honestly explains how to tell from the words after the comma in the title and from the verbs in the duties.

Then sort the lines into required, wish and missing, and make the preparation table. The kind of job tells you where to spend your time. For a product analytics job like Parlo’s, SQL, experiments and product cases matter most. For an ML job, the plan below still helps, but add Python and modelling practice.

Step 2: Prepare one analysis that changed a decision

Most product cases start with your own work: “Tell me about an analysis or experiment that changed a decision.” Choose one, or two at most. The best choice is not the most complex analysis. It is the one where you can explain every step and where something really changed because of it.

For that analysis, write short answers to the levels that a serious interviewer goes through. Use real numbers wherever you have them.

1. The question: what did someone need to decide, and who was it?
2. The data: where did it come from, and what was wrong with it at first?
3. The method: what did you do, and what else did you consider? Why did you choose this way?
4. How you knew it was real: how many users or rows, what interval or test, and what could have made the result look better than it was?
5. The decision: what did the team do because of your work? If they did not follow your advice, say that too.
6. What you would do differently: with more time, more data, or what you know now.

Level 4 is where many candidates stop having answers. You saw this with Chloe, who had run about 30 tests and still had to think hard about why stopping early is a problem. If your answer to level 4 is “the tool said it was significant”, go back to the analysis now. Find the sample size, the interval, and the dates. Ask yourself what else happened in those weeks.

Level 5 matters too. An analysis that changed nothing is not a bad story, if you can explain why. But an interviewer for a product team wants to hear that you care what happens after the analysis.

If you have no work experience with data, choose a project where you asked a real question of real data, and go through the same levels. Inés did this with public data about language learning. Read our advice as well.

Step 3: Practise SQL that you can explain and check

Parlo’s SQL screen allows an AI assistant. More companies now have a round like this, and others ban AI completely. Prepare for both.

Without AI: practise the queries that product teams use every week. Joins, especially a LEFT JOIN and what it does to users with no activity. Counts by day and by week. Retention: of the users who joined in a week, how many were active 30 days later? Funnels: how many users reached each step? Window functions for “first”, “last” and “previous”. Our SQL lessons Join tables, Aggregate correctly and Time and ranking cover these.

With AI: the skill is not the prompt. The skill is checking. Ask an assistant to write a retention query for a small practice database, and then check it like a careful colleague would:

• Read every line out loud, and say what it does.
• Count the rows before and after each join. Did a join repeat rows?
• Take one user whose numbers you know, and follow them through the query.
• Ask what happens to users with no rows in one of the tables.
• Compare the final number with something you know is true, for example the total number of users.

Do this five or six times with different queries. You will start to see the same kinds of mistakes. That is exactly what the interviewer wants to see you notice.

Step 4: Say the statistics in plain words

In a product case, you do not calculate much. You explain. So practise explaining these ideas to someone who does not do statistics, in two or three sentences each, with no formulas:

• What a confidence interval tells you, and what it does not.
• What a p-value is, and the common wrong reading (“a 96% chance that the feature hurts retention”). You saw Artem correct this, politely, when a product manager said it.
• What power is, and why a small test can miss a real effect.
• Why looking at the results every day and stopping when they look good gives you false results.
• What a novelty effect is: people try something new because it is new, and then stop.
• How a total can go down while every group goes up, when the mix of groups changes (Simpson’s paradox).
• Why a before-and-after comparison can lie: the season, a holiday, a marketing campaign.

A good test: explain each one to a friend who is not technical, and then ask them to explain it back to you. If they cannot, simplify. Our lessons Estimate uncertainty, Samples and populations and Compare alternatives help with the ideas under these words.

Step 5: Rehearse a product case

The product case is usually the most important interview for a product data scientist. You can practise it without a company. Take an app that you use every day. Invent a situation like Parlo’s: a new feature, one number that went up, one number that went down, and a manager who wants to decide soon. Write it in three or four sentences, like Thandiwe’s opening.

Then answer it out loud for 25 minutes, with a timer. Use this order, but do not read it like a list:

1. Ask before you answer. How were the users chosen? Compared with whom? Over which dates? What exactly does each metric count?
2. Check that the comparison is fair. Season, platform, the kind of user who gets the feature, novelty.
3. Decide what “good” means. One main metric, and two or three metrics that must not get worse. For Parlo, that was the hard part: activity, learning and money do not always move together.
4. Design the proper test. Who is randomised, what is measured, for how long, and what you decide before you look.
5. Say what you would recommend this week. With how sure you are, and what would change your mind.

Step 5 is where many strong candidates fail. Rahul had the most careful plan of all five candidates, and he still struggled with “What would you tell Kenji on Friday?” Practise that sentence separately. Write it, say it, and make it shorter each time.

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

Step 6: Prepare for the take-home and the presentation

A take-home with a time limit checks your judgement more than your code. Practise with a small public dataset and a three-hour timer.

• Spend the first 20 minutes on the question, not the data. What decision would this help? What would a useful answer look like?
• Check the data before you analyse it. Missing values, duplicates, strange dates. Our lesson Profile before changing shows how.
• Start your report with the answer. One page: the recommendation, the main numbers, how sure you are, and what the data cannot tell you. The method comes after.
• Declare your AI use clearly, if AI is allowed. Write which tool you used, for which parts, and what you checked yourself. Gabriel did this in a few honest lines, and it helped him.
• Stop at the time limit. If you go over, say so. A list of “what I would do with more time” is a strength, not a weakness.

For the presentation, practise for 15 minutes, not 30. The rest of the time is questions. Imagine that a product manager is in the room, and that they will act on what you say tomorrow.

Step 7: Get interviewed by a person

Practice alone is useful, but it cannot surprise you. Ask a friend or a former colleague, ideally a data scientist or an analyst, to run a 45-minute product case with you. Give them your case from step 5, with some extra facts that they give you only if you ask the right question. Ask them for one strength and two things to improve.

If you can, do one more practice with someone who is not a data person, such as a product manager or a friend from another job. Give them your Friday recommendation and see if they understand it. Their questions are very close to the questions of a real product manager in a values interview.

You can also practise with an AI assistant: ask it to play a strict interviewer who follows up on your answers and holds back facts until you ask. This is good practice. It is very different from using AI in a round where it is not allowed, which we ask you never to do (our advice).

Step 8: Prepare for the edge

You will reach the edge of your knowledge in every good interview. For data scientists, the edge is often in one of three places: the statistics under a method that a tool did for you, a kind of model you never built, or how to measure something that is hard to count, like learning. Prepare for it like any other part.

Write down three topics from your posting where you expect to reach your edge. For each one, write what you do know, and how you would find out the rest. Then practise saying it: “I haven’t done that myself. What I know is… If I had to decide today, I would start by…” It is also fine to ask the interviewer what the team has tried. Gabriel did exactly that when the conversation reached the measurement of learning.

Also prepare for the other kind of edge: when someone in the interview says something that you think is wrong. Know your main topics well enough to explain your view with a reason or an example, 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 stage, from your preparation table and from Read it honestly. Good questions for a data scientist are about how decisions are made: who decides when an experiment is finished, what happens when the data says no, and how much time goes to reports. They show that you think like someone who will do the job. They also give you the information that you need to decide.

On the day

• Ask at the start what is allowed in each round: notes, a whiteboard, an AI assistant. Then follow the rules exactly.
• For a video interview, test your camera, microphone and screen sharing the day before. Close everything that you do not need.
• In the case, it is normal to say “Can I take a minute to think?” and then think in silence. Write the numbers down. Draw a small table if it helps.
• If you did not understand a question, ask. “Do you mean retention of all users, or only new users?” is a good question, not a weak one.
• Your English does not need to be perfect. The interviewer listens for your thinking (our advice).
• Treat the interviewer as a future colleague. You are also finding out if you want to work with them.

After the interview

Write down every question that was hard, 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. Rahul’s feedback about communication was hard to hear, and he still thanked Thandiwe for it months later, because it helped him in his next interviews.

Remember that some of the result is outside your control (our advice). There may be only one vacancy. A team may open a different role a month later. Gabriel and Inés, two of the five candidates in this guide, were each offered something good that was not the job they applied for. Keep going, 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 or other studies.

Week	Main work	Out loud
1	Read the posting, decide the kind of job, and make the preparation table. Write the six levels for your main analysis. Do SQL practice without AI on three days.	Say your analysis in two minutes, and record it. Explain three statistics ideas to a friend.
2	Check AI-written SQL on three days. Do one three-hour take-home practice, and write the one-page answer.	Rehearse two product cases with a timer. Practise the Friday recommendation each time.
3	Fix the gaps that weeks 1 and 2 showed. Prepare your three edge topics and your questions.	One mock case with a data person, and one Friday recommendation for a person who is not a data person.

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