Data Scientist Top 100 Interview Questions

Stay helpful while keeping the analysis honest: reframe the request into a question the data can answer fairly, and agree in advance what result would change the plan. Producing a one-sided analysis damages trust in every later analysis you deliver.

1. Understand the need: often the stakeholder needs a business case for leadership, or a way to monitor whether the decision works.
2. Reframe the question: from "prove this works" to "what impact should we expect, and how will we know if it is working?"
3. Agree on the method and metrics first, before looking at results, so the outcome cannot steer the method.
4. Present all the evidence, including what supports and what weakens the case, with clear uncertainty.
5. Offer constructive options: a staged rollout or experiment, so the decision can proceed while its effect is measured.
6. Escalate calmly if asked to misrepresent results, framing it as protecting the team's credibility.

Interview tip: this question tests integrity and influence together. A strong answer shows you can keep a working relationship while refusing to bend the numbers.

Predicting who will churn is different from predicting who can be persuaded to stay. A model can rank churners accurately while the campaign targets people it cannot help.

flowchart TD
  A["Campaign showed no churn reduction"] --> B{"Was there a random control group?"}
  B -->|No| C["Effect cannot be measured: add a holdout"]
  B -->|Yes| D{"Did targeted users receive and notice the offer?"}
  D -->|No| E["Fix delivery, timing or channel"]
  D -->|Yes| F{"Were targets persuadable?"}
  F -->|No| G["Use uplift modeling on experimental data"]
  F -->|Yes| H["Improve the offer itself"]

Common reasons:

• Wrong targets: the highest-risk customers may already have decided to leave, while others would have stayed anyway.
• Timing: by the time risk is predicted, the decision has been made; earlier signals may be needed.
• The offer: a discount does not fix a product problem, such as poor delivery reliability.
• Delivery: emails unopened or offers not shown.
• Measurement: without a random holdout, a real effect can be hidden by seasonal churn changes, or a false one can appear.

The fix is usually to test interventions directly and target by estimated uplift rather than by churn risk.

Run a randomized experiment at the user level, and measure the effect on whole-store outcomes, not just on clicks within the new section. Recommendations often move purchases from one place to another rather than creating new ones.

flowchart LR
  A["New recommendation section"] --> B["Clicks on recommended items"]
  B --> C["Purchases from recommendations"]
  A --> D["Fewer searches and category visits"]
  D --> E["Fewer purchases from other paths"]
  C --> F["Net change in store revenue"]
  E --> F

Metrics:

• Primary: revenue or orders per user across the whole store.
• Secondary: engagement with the section, items per order and discovery of new categories.
• Guardrails: page load time, return rates and diversity of items sold, so a few bestsellers do not take over.

Design details:

1. Randomize users, so each sees a consistent page.
2. Run for at least two weeks, since repeat visits matter and novelty fades.
3. Count purchases from all paths, to capture cannibalization.
4. Check effects for new and returning users separately, since recommendations depend on history.

Report the net lift and how much of the section's attributed sales were genuinely additional.

Price elasticity is the percentage change in quantity sold for a 1% change in price. The best estimate comes from randomized price variation; observational price changes are confounded by demand, because prices are often raised when demand is already high.

Methods, from most to least reliable:

1. Price experiments: randomize prices by region, time slot or customer group, within legal and fairness limits.
2. Natural experiments: price changes driven by cost shocks or rule changes rather than by demand.
3. Regression on historical data: regress log quantity on log price, controlling for season, promotions and competitor actions; the coefficient on log price is the elasticity.

Interpreting it:

• Elasticity below −1 means demand is elastic: raising the price lowers revenue.
• Between −1 and 0, demand is inelastic: raising the price raises revenue, though volume falls.
• Elasticity often differs by segment and over time; short-term responses can be smaller than long-term ones.

Revenue is not profit: a price change that lowers revenue can still raise profit if margins improve enough.

Give planners a range tied to decisions, not a single number. A point forecast hides the risk that drives most planning choices, such as how much stock to hold or how many staff to schedule.

Practical advice:

1. Ask which decision the forecast feeds, then present the quantile that matches the cost of error; understocking a key product may justify planning to the 90th percentile.
2. Show history alongside the forecast, with past forecast errors, so users can see how reliable it has been.
3. Name the main assumptions, such as no new competitor, and say what would change the forecast.
4. Update forecasts on a regular schedule, and track accuracy so trust is earned over time.

A marketplace succeeds only when both sides are healthy and they find each other efficiently, so the dashboard needs metrics for demand, supply and the matching between them, not just total revenue.

Design principles:

1. Lead with a north star, such as completed transactions per week, then break it into the drivers above.
2. Segment by market: a healthy national total can hide cities with too few suppliers or too few buyers.
3. Show balance indicators, such as requests per available provider, because an imbalance on either side hurts both.
4. Track quality alongside volume, so growth through low-quality listings is visible.
5. Annotate changes, such as pricing or incentive programs, which often move one side at the expense of the other.

The platform must turn assignment and event data into trustworthy, consistent scorecards for every experiment, without each analyst rewriting the statistics.

flowchart LR
  A["Assignment service"] --> B["Exposure logs"]
  C["Product event logs"] --> D["Metric definitions layer"]
  B --> E["Join exposures to metrics per user"]
  D --> E
  E --> F["Statistics engine"]
  F --> G["Quality checks: ratio mismatch, guardrails"]
  G --> H["Experiment scorecard"]

Key components:

1. Assignment: deterministic hashing of user IDs with an experiment-specific salt, so assignment is stable and independent across experiments.
2. Exposure logging: record when a user actually encounters the change, and analyze only exposed users.
3. Shared metric definitions: one version-controlled definition per metric, reused by every experiment.
4. Statistics engine: correct variance for ratio metrics, variance reduction with pre-period data and multiple-comparison handling.
5. Automatic quality checks: sample ratio mismatch, data freshness and guardrail breaches, which block scorecards until resolved.
6. Scorecard: effect sizes with intervals, not just p-values, plus a record of the pre-registered decision rule.

Store every result and decision, so the organization can learn which kinds of changes tend to work.

Revenue per user is heavily skewed: a handful of very large buyers can create or erase an apparent effect. Make the metric robust in a way that is decided before the test, and apply it to both groups identically.

Options:

• Capping: replace values above a high percentile, such as the 99.9th, with that percentile's value, computed on the combined data. This keeps most information while limiting any single user's influence.
• Log transformation: analyze the logarithm of revenue plus one, which reduces skew but changes the question to proportional effects.
• Separate metrics: split revenue into conversion rate and revenue per buyer, which are each less noisy.
• Rank-based tests: check whether the distribution shifted, as a complement to the capped mean.

Cautions:

• Never remove outliers after seeing which group they are in.
• Investigate extreme values: some are fraud or test accounts that should be excluded by rule.
• Report capped results as the decision metric, and the uncapped total as context, since real revenue includes big buyers.

Incremental impact is the extra conversions a channel causes, compared with what would have happened without it. Attribution reports do not measure this, because they credit channels for conversions from customers who would have bought anyway.

Practical approach:

1. Use holdout experiments for the largest channels, repeated periodically, since effects change.
2. Use the results to calibrate an aggregate model, which then guides budget allocation across all channels.
3. Measure incremental cost per acquisition: spend divided by incremental conversions, not attributed conversions.

Branded search ads are a classic case: they often get credit for customers who were already searching for the brand.

Start from what the feature is meant to change for users, then find observable behaviors that would change if it worked. Features such as a redesigned settings page or better error messages rarely move revenue directly, but they leave traces.

1. State the intended outcome: for example, "users can change notification preferences without contacting support".
2. Find behavioral proxies:
   • Task success rate and time to complete the task.
   • Fewer support tickets on the topic.
   • Fewer repeated attempts, back-navigation or abandonment.
3. Add direct feedback: short in-product surveys or usability tests with a handful of users.
4. Check guardrails: the change should not hurt engagement elsewhere.
5. Decide the threshold in advance: for example, a 20% drop in related tickets.

When effects are hard to detect: long-term or rare outcomes may need a long holdout, or qualitative evidence combined with a before-and-after comparison.

Being explicit about which proxy you chose and why makes the result credible even when it is imperfect.

Surveys capture opinions and intentions that behavior data cannot, but they come with biases in who answers and how questions are understood.

Biases to check:

• Nonresponse: the people who answer may differ from those who do not; compare respondents' known characteristics, such as tenure or usage, with the full population, and weight if needed.
• Question wording: leading or double-barreled questions, such as "How fast and reliable was delivery?", produce unclear answers.
• Scale effects: people tend to agree with statements, and cultures use scales differently.
• Stated versus actual behavior: "would you pay for this?" overstates real purchasing.

Good practice: pilot questions with a few users, keep surveys short, and link responses to behavior data where privacy rules allow, so opinions can be checked against what users actually do.

Translate uncertainty into ranges and consequences that relate to the decision, and keep the statistics in an appendix. Stakeholders need to know how confident to be and what could go wrong, not how the interval was computed.

Techniques that help:

1. Use natural frequencies: "about 1 in 20" is easier than "5%".
2. Show ranges on charts, such as shaded bands, instead of single lines.
3. Describe the range in money or customers affected, for example "between 2 and 4 crore rupees per year".
4. Be explicit about what the data cannot tell you, such as long-term effects.
5. Pair the uncertainty with a recommendation, so the message is actionable.

Interview tip: demonstrating one clear sentence for a result, out loud, is often more convincing than describing communication principles in general.

Put the answer first, then the evidence, then the details. Busy readers decide after the first few lines, so those lines must contain the conclusion, its confidence and the recommended action.

1. Headline: one sentence that answers the question, such as "Free shipping above 999 rupees increased orders by 6% without hurting margins; we recommend keeping it."
2. Key evidence: two or three findings with numbers and uncertainty.
3. Recommendation and options: what to do, alternatives and their trade-offs.
4. Caveats: limitations that could change the conclusion, stated plainly.
5. Next steps: owners and dates.
6. Appendix: methods, definitions, data sources and extra charts.

Writing habits:

• Use the stakeholder's terms, not table and column names.
• Make each chart title a finding, not a description of the axes.
• Cut analyses that do not support the conclusion or a caveat, even if they took effort.
• Keep the summary to one page when possible.

Share a draft early with the main stakeholder; surprises in a final review usually mean the question was misunderstood.

Rank requests by the value of the decision each one informs and by the effort required, then make the priorities visible so stakeholders can see why their request waits.

How to estimate impact:

• Ask what decision the analysis supports, how much money or how many customers it affects, and when the decision must be made.
• Requests with a fixed decision date and a large impact win, even if they are less interesting.

Reducing the queue over time:

1. Build dashboards and self-service tools for recurring questions.
2. Keep a shared, ranked backlog agreed with team leads.
3. Time-box exploratory work, and share interim answers.
4. Say no clearly and early, which is kinder than a delayed "maybe".

Anyone, including your future self, should be able to rerun the analysis and get the same numbers. That requires keeping the data, code, environment and decisions together, not scattered across notebooks and messages.

flowchart LR
  A["Snapshot or dated query of the source data"] --> B["Version-controlled queries and code"]
  B --> C["Pinned library versions and fixed random seeds"]
  C --> D["Automated run from start to finish"]
  D --> E["Outputs with the code version recorded"]

Practices:

1. Version control for queries, code and the written summary.
2. Fixed inputs: record the exact query and the time it ran, or save a snapshot, because source tables change.
3. One entry point: a script or pipeline that runs every step in order, rather than notebook cells run by hand in an unknown order.
4. Pinned environment: record library versions, so results do not drift when packages update.
5. Seeds: fix random seeds for sampling, bootstrapping and model training.
6. Documented decisions: exclusions, definitions and assumptions written next to the code.

Reproducibility pays off when a stakeholder asks a follow-up months later, or when a surprising result needs checking before a big decision.

Data science can harm people through privacy violations, unfair treatment, manipulation or misleading conclusions. Managing these risks is part of doing the work well, not an extra step.

Main risks:

• Privacy: collecting more personal data than needed, or analyses that reveal information about individuals, such as inferring health conditions from purchases.
• Unfair outcomes: models or policies that treat groups differently, often because historical data reflects past unfairness.
• Manipulation: experiments or designs that exploit users, such as hiding cancellation options to reduce churn.
• Misleading results: overstated certainty, cherry-picked segments or charts that steer decisions badly.

How to manage them:

1. Use the minimum data necessary, aggregate and anonymize where possible, and follow consent and retention rules.
2. Check outcomes across groups before and after launch.
3. Ask whether users would be comfortable if they knew how their data was used.
4. Review experiments that could harm users, with a clear escalation path.
5. Document limitations and uncertainty honestly in every deliverable.

An analysis is ready when more work is unlikely to change the decision it supports. Perfection is rarely the goal; the cost of waiting must be weighed against the risk of being wrong.

Signs it is ready:

• The main conclusion survives reasonable checks, such as different time windows, definitions or exclusion rules.
• The numbers reconcile with a trusted source, such as finance totals.
• The remaining uncertainty would not flip the recommendation.
• You can explain the main caveats in a sentence each.

Signs it is not ready:

• The result changes direction with small, defensible changes to the method.
• A surprising finding has not been checked for a data error, which is the most common explanation for surprises.
• You cannot yet explain why the result happened.

Practical habits:

1. Agree on the deadline and the needed confidence at the start.
2. Share interim findings labeled as preliminary when a decision is imminent.
3. Ask a colleague to review the logic and the key query.
4. State what further work would add, so stakeholders can choose whether to wait.

Launches often deliver less than the experiment suggested. Some of the gap is statistical, and some comes from differences between the test and the real launch.

flowchart TD
  A["Effect smaller after launch"] --> B["Winner's curse: only lucky estimates crossed the threshold"]
  A --> C["Novelty faded over time"]
  A --> D["Launch population differs from the test audience"]
  A --> E["Other launches interact or overlap"]
  A --> F["Seasonality or market changes"]
  A --> G["Implementation differs from the tested version"]

The winner's curse: when only significant results are shipped, the shipped estimates are biased upward, especially for underpowered tests. Shrinking estimates toward typical past effects gives more realistic forecasts.

How to check after launch:

1. Keep a small holdout after launch to measure the real effect directly.
2. Compare the launch audience and timing with the test.
3. Check that the shipped implementation matches the tested one, including performance.
4. Combine the effects of many launches carefully; they rarely add up exactly.

Track predicted versus realized impact across launches, so forecasts improve over time.

Tell one project as a story about a decision: the business question, your approach, the key judgment calls, the result and its impact. Interviewers want to hear how you think, not a list of techniques.

1. Context: the business problem, why it mattered and who needed the answer.
2. Your role: what you did personally, separate from what the team did.
3. Approach: the data, the method and why you chose it over simpler or more complex options.
4. A hard moment: a data problem, a confounder or a surprising result, and how you handled it.
5. Result: the finding with its uncertainty, and the decision it led to.
6. Impact: measured outcomes, such as "retention rose 3 points in the test markets", or what changed in the business.
7. Reflection: what you would do differently now.

What the interviewer is listening for:

• Clear framing of the question before any method.
• Honest treatment of uncertainty and limitations.
• Evidence that your work changed a decision.

Interview tip: prepare a two-minute version and a ten-minute version of the same project, since interviewers vary in how deep they want to go.

Choose a real example, describe it without defensiveness, and focus on how you found the problem or resolved the disagreement and what you changed afterwards.

If your analysis was wrong:

1. What happened: the conclusion, the decision it influenced and how the error was discovered.
2. Ownership: how you told stakeholders quickly and corrected the record.
3. Root cause: for example, a join that duplicated rows or an unchecked definition change.
4. Prevention: reconciliation checks, peer review or tests you added.

If a stakeholder disagreed:

1. Understand the objection: often it rests on knowledge you lacked, such as a pricing change in one region.
2. Find shared ground: agree on what evidence would settle the question.
3. Test it: run the extra analysis or experiment, and accept the result either way.
4. Outcome: what was decided and how the relationship developed.

What the interviewer is listening for:

• Honesty and quick correction, rather than hiding mistakes.
• Respect for domain expertise combined with commitment to evidence.
• Concrete process improvements that came from the experience.