Interview Insights · Data Scientist
Why Data Scientists Who Ask Questions Back Impress Me Most
Quick summary — Clarifying questions
Asking good questions back shows me you understand that most data science failures begin with a badly defined problem, not a weak algorithm. Open-ended prompts like 'predict churn' or 'build a recommendation system' are deliberately vague. I want to see whether you notice. Candidates who ask what the target means, what decision the model supports, what data exists at prediction time and what constraints apply are showing me exactly the skill that saves projects in real teams. The key is to ask a few focused questions, not a long list.
In this guide you will learn:
- Why questions back are one of the strongest data science signals
- The four groups of clarifying questions and when to use each
- How a vague target becomes a precise label, with SQL and pandas
- How constraints change the model you choose
- How many questions are enough, and how to move on
SECTION 01Why a question back is worth more than an algorithm
In real teams, a data scientist rarely receives a clean problem. They receive a request: 'Can we predict which users will leave?' Before any model can be built, someone has to decide what 'leave' means, how far ahead to predict and what will happen with the prediction. If that step is skipped, the model can be accurate and still useless.
That is why I reward questions back. A candidate who asks 'is churn a cancelled subscription, or thirty days with no activity?' is doing the most valuable part of the job in front of me. A candidate who replies 'I would use a random forest' has skipped it.
| Question group | Example question | What the answer changes | Why I value it |
|---|---|---|---|
| Target | Does churn mean cancelling, or going inactive? | The label and the training data | Wrong label means a useless model |
| Horizon | Predict churn in the next week or next quarter? | Features, data window and urgency | Shows time-awareness |
| Action | What happens to users we flag? | Threshold, metric and cost of errors | Links the model to value |
| Constraint | Does the team need reasons for each prediction? | Model family and explanation method | Shows practical judgement |
Interviewer: We want to predict churn for our app.
Candidate: Sure. I would collect user features like age,
sessions and purchases, handle missing values, then try
logistic regression, random forest and XGBoost, tune them
with grid search and pick the best AUC.
Interviewer: What is your target variable?
Candidate: Churn... whether the user churned.Interviewer: We want to predict churn for our app.
Candidate: Before I design anything, three quick questions.
First, is churn a cancelled paid plan, or users who stop
opening the app? Those are different problems.
Second, how far ahead do you need to know? A week ahead
supports a quick nudge; a quarter ahead supports pricing.
Third, what happens to flagged users? A discount, a call,
an email? That tells me how costly false alarms are.
Interviewer: Paid cancellations, 30 days ahead, and we
send an in-app offer.
Candidate: Great. Then the label is 'cancelled within
30 days of the snapshot date', and because an in-app offer
is cheap, I can favour recall over precision.
Look at what three questions bought the second candidate. They now have a precise label, a horizon and a reason to prefer recall. Every decision after this point will be easier to defend, and the interviewer has seen them think.
SECTION 02Turning a vague target into a precise label
Words like churn, active user, fraud and conversion feel obvious until you try to write them as code. Then the questions appear: active on which day? Counted per user or per account? What about users who cancel and resubscribe a week later? Candidates who ask these questions in the interview usually know because they have written labels before.
Once the interviewer answers, show that you can turn the definition into code. Writing the label as SQL or pandas, even roughly, proves that the definition is now concrete enough to train on.
| Vague term | Questions to ask | One precise version | Edge case to mention |
|---|---|---|---|
| Churn | Cancel or go inactive? Within what period? | Paid plan not active 30 days after snapshot | Cancels then resubscribes quickly |
| Active user | Any event, or a meaningful action? Per day or week? | 3+ sessions in the last 7 days | Bots and test accounts |
| Fraud | Confirmed chargeback, or flagged by rules? | Chargeback confirmed within 60 days | Labels arrive weeks later |
| Conversion | Signup, first purchase, or paid plan? | First paid order within 14 days of signup | Free trials counted as paid |
-- PostgreSQL. Label: was a paid user at the snapshot date
-- still subscribed 30 days later? 1 = churned.
WITH snapshot AS (
SELECT DISTINCT user_id, DATE '2024-06-30' AS snapshot_date
FROM subscriptions
WHERE start_date <= DATE '2024-06-30'
AND (end_date IS NULL OR end_date >= DATE '2024-06-30')
)
SELECT s.user_id,
s.snapshot_date,
CASE WHEN EXISTS (
SELECT 1
FROM subscriptions AS x
WHERE x.user_id = s.user_id
AND x.start_date <= s.snapshot_date + 30
AND (x.end_date IS NULL
OR x.end_date >= s.snapshot_date + 30)
)
THEN 0 ELSE 1 END AS churned_30d
FROM snapshot AS s;import pandas as pd
# events: user_id, session_id, event_ts
ref = pd.Timestamp("2024-06-30")
events["event_date"] = pd.to_datetime(events["event_ts"]).dt.normalize()
last_7 = events[(events["event_date"] > ref - pd.Timedelta(days=7)) &
(events["event_date"] <= ref)]
sessions = last_7.groupby("user_id")["session_id"].nunique()
active = sessions[sessions >= 3].index
print(len(active), "active users in the week ending", ref.date())
# Say aloud: "I count distinct sessions, not events, so one
# long session full of clicks does not make someone active."
Notice the resubscription edge case in the table. Because the SQL checks whether the user is subscribed on day thirty, someone who cancels and returns within the window is not counted as churned. Whether that is right is a business choice, which is exactly why you ask.
SECTION 03Constraint questions that change the model you choose
The last group of questions is about limits. How fast must the prediction be returned? Does the team need a reason for every decision? How often is the data refreshed? These answers can change your whole approach. A loan approval model that must explain each decision to a customer is a different project from a product recommendation model that must respond in milliseconds.
Asking about constraints also protects you in the interview. If you propose a large ensemble and the interviewer later reveals the model must run on a phone, you look careless. If you asked first, you look prepared.
| Constraint question | If the answer is... | Effect on design | Spoken follow-through |
|---|---|---|---|
| Do decisions need explanations? | Yes, regulators or customers ask | Prefer interpretable models or clear reason codes | I would start with logistic regression and a scorecard |
| How fast must it respond? | Within milliseconds, online | Precompute features, keep model light | Batch scoring is ruled out |
| How often does data refresh? | Once a day | Daily batch scoring is enough | No need for real-time features |
| How costly is a false alarm? | Very costly, e.g. blocking payments | Favour precision, add human review | I would tune for precision at a fixed recall |
RECOMMENDATIONS
- What is recommended: products, articles, people?
- Where is it shown, and how many slots?
- How do we handle new users with no history?
FORECASTING
- What level: store, product, or store-product?
- How far ahead, and how often is it refreshed?
- Which decisions use it: ordering, staffing?
FRAUD
- How long until a fraud label is confirmed?
- Block, review, or only flag?
- Is a human reviewer available, and how many cases a day?
PRICING
- Can prices change per user, or only per segment?
- Are there legal or fairness limits?HOW MANY QUESTIONS IS ENOUGH?
Aim for two to four focused questions, then commit.
If the interviewer says 'you decide', do not stall.
State an assumption and move on:
"Then I will assume churn means a cancelled paid plan,
predicted 30 days ahead, with a cheap in-app offer.
If any of that is wrong, the label and threshold change,
but the overall approach stays the same."
This shows you can work with uncertainty, which is the
normal state of real projects.
In Uncodemy mock interviews, the 'you decide' reply is one of the first things we practise with data science students. Many candidates freeze when the interviewer refuses to clarify. The fix is simple: state your assumption out loud, explain what would change if it were different, and continue.
SECTION 04Worksheet: practise asking the right questions back
Take any open-ended ML prompt and fill this worksheet before you start solving. Practise with a partner who answers some questions and refuses others, so you get used to both.
PROMPT: __________________________________
Target: what exactly is predicted? ______________
Horizon: how far ahead? _________________________
Action: who uses it and what do they do? ________
Data: what is known at prediction time? _________
Constraint: speed, explanation, budget? _________
Pick the 3 questions whose answers would change
your design the most. Ask only those first.USE ONE PER DAY
1. Predict which delivery orders will be late.
2. Recommend courses to learners on an edtech app.
3. Detect fake reviews on a shopping site.
4. Forecast daily demand for a grocery chain.
5. Predict which leads a sales team should call first.
6. Flag suspicious insurance claims.
7. Estimate the price of a used car from a listing.
For each: ask 3 questions, then state assumptions
for anything left unanswered.PARTNER SCORES EACH ATTEMPT (Y / N)
[ ] Asked about the target definition
[ ] Asked about the horizon or timing
[ ] Asked what action follows the prediction
[ ] Asked at least one constraint question
[ ] Asked no more than five questions before starting
[ ] Turned each answer into a stated design choice
[ ] Stated assumptions when an answer was refused
Target: all seven ticked by the end of the week.
SECTION 05Habits that make your questions sound sharp, not stalling
The difference between a sharp question and a stalling one is mostly about focus and follow-through.
- Explain why you are asking — Add a short reason, such as 'because a week ahead and a quarter ahead need different features', so the question sounds purposeful.
- Ask the highest-impact question first — The target definition usually changes the most, so start there.
- Offer options, not open questions — 'Is churn cancellation or inactivity?' is easier to answer than 'what is churn?'
- Close the loop — After each answer, say the design decision it leads to before asking the next question.
- Save some for the end — Questions about how the team measures success fit naturally in the final minutes of the interview.
SECTION 06Interview Q&A — Clarifying questions
Q1You are asked to build a churn model. What do you ask first?
I would ask what churn means for this business, for example cancelling a paid plan or becoming inactive, how far ahead the prediction is needed, and what action will be taken for flagged users. Those three answers define the label, the features and the cost of mistakes.
Q2What if the interviewer refuses to answer your clarifying questions?
I would state reasonable assumptions out loud and continue, for example 'I will assume churn is a cancelled plan within 30 days'. I would also say briefly how the design would change if the assumption were different, which shows flexibility.
Q3Why does the prediction horizon matter?
It decides which data counts as features and which is the future. A one-week horizon uses recent activity and supports quick actions, while a quarter-ahead horizon needs more stable signals and supports slower decisions such as pricing changes.
Q4How do business constraints affect model choice?
If explanations are required, interpretable models or clear reason codes are preferred. If responses must be very fast, the model and features must be lightweight. If false alarms are expensive, I tune for precision and may add human review.
Q5How many clarifying questions should you ask in an ML case interview?
Usually two to four focused questions, starting with the ones that would change the design most. Then commit to an approach and state assumptions for anything still open. Asking too many questions can look like avoiding the problem.
SECTION 07Test yourself — Clarifying questions quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Should I ask questions in a data science case interview?
Yes. Clarifying the target, the action, the available data and the constraints is expected and is one of the strongest signals of real problem-solving skill. Keep it to a few focused questions.
What clarifying questions should I ask in a machine learning interview?
Ask what exactly is being predicted, over what horizon, what action follows a prediction, what data is available at prediction time and what constraints apply, such as speed or explainability.
Is asking too many questions bad in an interview?
It can be. A long list can look like stalling. Ask the two to four questions that would change your design most, then commit and state assumptions.
How do I define a target variable for a churn model?
Agree on what churn means, such as a cancelled plan, choose a snapshot date and a horizon such as 30 days, and label each user by whether the event happened within that window. Note edge cases like quick resubscriptions.
What questions should I ask the interviewer at the end of a data science interview?
Ask how the team defines success for its models, how predictions are used in decisions, what the biggest data quality challenge is and how projects move from prototype to production.
Does Uncodemy help with Data Scientist interview answers?
Yes. Uncodemy's Data Science Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise Data Scientist interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Learn to frame problems before solving them
Our Data Science Training Course covers machine learning, statistics and Python with case-style projects, and includes mock rounds where you practise clarifying vague business prompts.
Talk to a counsellor for current fees- Case-based ML projects
- Problem framing practice
- SQL and pandas labs
- Mock case interviews