What you need to know
Work through ten Data Scientist interview questions on business decisions, SQL joins, missing data, experiments, sampling bias and communicating uncertainty, with practical answer explanations.
Work through ten Data Scientist interview questions on business decisions, SQL joins, missing data, experiments, sampling bias and communicating uncertainty, with practical answer explanations.
These are original practice questions, not questions reported from a particular employer. Every scenario below is hypothetical. Use the answers to understand the reasoning, then explain the decision in your own words and connect it to work you actually did.
How to practise
First answer aloud without reading. State the goal, assumptions, proposed approach, checks and trade-offs. Then compare your reasoning with the answer, tackle the follow-up and write down one gap to practise. Aim for a clear two-minute initial explanation; expand when asked. This timing is a practice suggestion, not an interview rule.
Role-based questions and detailed answers
1. How do you turn a vague business question into an analysis?
Answer: Identify the decision, who will make it and what action could change as a result. Define the population, outcome, observation window and practical constraints. Agree on a useful comparison before selecting a method. An analysis is valuable when it informs a decision; a technically impressive model answering a different question is not a substitute.
Hypothetical scenario: A manager asks why growth is bad without identifying whether they mean acquisition, activation or retention.
Follow-up: Which clarification would you ask before querying the data?
Common mistake: Choosing an algorithm before agreeing on the decision and metric.
2. Why can a SQL join inflate revenue?
Answer: Check the grain and uniqueness of both tables before joining. A one-to-many or many-to-many relationship can repeat monetary values across result rows. Aggregate at the intended business grain or use an appropriate deduplicated relation, then reconcile counts and totals before and after the join. DISTINCT is not a general repair for an incorrectly defined relationship.
Hypothetical scenario: Each order joins to several support tickets, and the order value is summed once per ticket.
Follow-up: How would you preserve ticket counts without repeating order revenue?
Common mistake: Adding DISTINCT until the output looks plausible without explaining table grain.
3. How do you distinguish a missing value from a true zero?
Answer: Investigate collection semantics before replacing anything. Zero can mean an observed absence, whereas null may mean not measured, unavailable or inapplicable. Examine missingness by source, time and outcome, and document how the analysis treats it. Any imputation introduces assumptions; assess sensitivity and preserve indicators where they carry legitimate information available at prediction time.
Hypothetical scenario: A sensor outage appears as null, while a functioning sensor records zero activity.
Follow-up: What would be lost by replacing both conditions with zero?
Common mistake: Treating every null as an observed zero for convenience.
4. Can an observational difference prove a product change worked?
Answer: Not by itself. Users exposed to a feature may differ in intent, timing or other conditions that also influence outcomes. Explain possible confounding and selection effects. A well-designed randomized experiment can support a stronger causal comparison, subject to its assumptions. If only observational data exists, qualify the conclusion and avoid presenting association as a measured treatment effect.
Hypothetical scenario: Customers who use a premium dashboard renew more often, but they also began with larger contracts.
Follow-up: What alternative explanation would you investigate first?
Common mistake: Calling a correlation the causal impact of the feature.
5. Why do assignment and measurement units matter in an experiment?
Answer: Define what is randomized and what is measured before analysing results. Multiple observations from one assigned unit may be dependent, so treating them as independent can overstate precision. Align analysis with the experimental design and consider interference between units. Explain exclusions and exposure consistently rather than choosing a convenient row-level test after seeing the outcome.
Hypothetical scenario: Companies are randomized, but individual employee sessions are analysed as if each session were independently assigned.
Follow-up: How could within-company similarity affect the reported uncertainty?
Common mistake: Assuming the number of rows equals the number of independent experimental units.
6. What does an inconclusive statistical result mean?
Answer: It means the data and chosen analysis did not establish the specified difference with the required evidence; it does not prove equivalence. Inspect effect estimates, uncertainty, sample size and practical relevance. Compare the interval with the decision threshold and discuss whether more data would help. Avoid repeatedly extending the test until a favourable result appears.
Hypothetical scenario: An experiment has a positive estimate but an interval that includes both negligible and valuable effects.
Follow-up: What decision can you justify without claiming the feature has no effect?
Common mistake: Interpreting a non-significant result as proof that two options are identical.
7. How can a reviewed sample misrepresent overall performance?
Answer: Review selection can depend on user complaints, model uncertainty or operational convenience. Those cases may not represent the population. Describe the sampling mechanism and collect a representative audit sample when estimating overall quality. Keep targeted failure analysis separate from population estimates; both are useful, but answer different questions and should not share an unqualified accuracy label.
Hypothetical scenario: Only users who report an incorrect recommendation contribute labels to the evaluation dataset.
Follow-up: What sampling plan would estimate quality beyond complaint cases?
Common mistake: Extrapolating the complaint error rate directly to every user.
8. How would you investigate a sudden metric change?
Answer: Verify instrumentation, metric definitions, processing completeness and denominator changes before explaining user behaviour. Segment by source, platform, cohort and time to locate the shift. Check releases and upstream changes, then form testable hypotheses. Preserve the distinction between a data defect and a real behavioural change so the response addresses the actual cause.
Hypothetical scenario: Conversion falls after a tracking release that stops recording purchases from one mobile browser.
Follow-up: Which reconciliation would separate missing events from lost sales?
Common mistake: Building a business narrative before checking whether measurement changed.
9. Why can comparing young and old cohorts be unfair?
Answer: Cohorts need comparable exposure and follow-up to support a fair outcome comparison. New users may not yet have had time to renew, churn or complete a purchase. Define a common observation window, account for incomplete follow-up and report the eligible denominator. Calendar changes and acquisition mix may still differ, so explain those limitations separately.
Hypothetical scenario: Last week's users appear to have lower thirty-day retention even though thirty days have not elapsed.
Follow-up: Which cohorts are currently eligible for that metric?
Common mistake: Counting users with incomplete follow-up as confirmed failures.
10. How should a recommendation communicate uncertainty?
Answer: Lead with the decision and the evidence that supports it, then state the main uncertainties and their consequences. Separate measured facts from assumptions and scenarios. Offer a bounded next action, such as a limited experiment or additional data collection, with a review trigger. Avoid excessive decimal precision when data quality or design limits the strength of the conclusion.
Hypothetical scenario: A small regional sample suggests demand, but collecting representative national data would delay launch.
Follow-up: What limited next step balances learning with the cost of a wrong decision?
Common mistake: Hiding uncertainty in an appendix while presenting the headline as certain.
Turn practice into evidence
Analyse a fictional conversion dataset with a written decision question. Document table grain, join checks, missing values and cohort follow-up. Propose an experiment separately from the observational findings, and write a one-page recommendation that distinguishes evidence, assumptions and uncertainty.
Score each response informally: 0 if you cannot explain it, 1 for a definition, 2 for an approach with checks, and 3 for justified trade-offs plus a failure-recovery plan. This is a self-study rubric, not a validated hiring assessment. Revisit weak answers and never invent project outcomes or experience.
Career roadmap and related jobs
Build the underlying skills with the Data Scientist career guide. For a shorter starting point, read AI interview answer frameworks.
Explore relevant live jobs. Listings are filtered by Data Science and can include adjacent roles. Read the employer's requirements and original posting before applying. Use one listing to select the questions most relevant to its responsibilities.
Methodology
Editorial synthesis of cited sourcesAI-assisted original educational practice material. These are not actual employer interview questions, reported interview experiences or hiring guarantees. Answers, hypothetical scenarios, follow-ups and self-assessment advice are original editorial synthesis. Official Google references support background concepts, not endorsements of these answers. Related jobs use a specialization filter and may include adjacent roles; availability changes. References checked 17 October 2026.
Read our editorial and research policy →Sources
- Machine Learning Crash Course
Google for Developers · Checked 17 October 2026
- Dividing datasets
Google for Developers · Checked 17 October 2026
- Classification: accuracy, recall, precision and related metrics
Google for Developers · Checked 17 October 2026