8 Data Science Intern Interview Questions to Practice

You've reviewed your notebook, refreshed SQL joins, and opened the interview link. Then the interviewer asks why you chose your evaluation metric, and the answer feels harder than explaining the model itself. You know the terminology, but turning that knowledge into a clear decision under pressure takes a different kind of preparation.

A data science intern interview tests whether you can frame a problem, reason through trade-offs, write reliable code, and explain your decisions without hiding behind jargon. The emphasis on reasoning makes sense: 7 in 10 companies considered analytical thinking essential in 2025, making it the most sought-after core skill in the World Economic Forum's employer survey. For your preparation, that means practicing why an answer works, not just remembering what it's called.

A credible intern answer doesn't require knowing everything. It requires making your assumptions visible and explaining how you'd check them.

Use these data science intern interview questions as performance drills. Give a concise answer, work through a realistic example, check assumptions, and connect the result to a business decision. Treat the model answers as scaffolds, not scripts to memorize.

For every drill, keep a portfolio artifact nearby: a query, validation plot, experiment plan, or documented cleaning decision. That gives you something concrete to discuss when the interviewer asks, “How have you applied that?”

1. Explain the difference between supervised and unsupervised learning

Start with the available target, not a list of algorithms. For a hypothetical retailer, predicting whether a customer will purchase again differs from grouping customers by purchasing behavior.

Model answer: Supervised learning uses examples with known target values to learn a mapping from inputs to outputs. Predicting a purchase is supervised if historical examples include the purchase outcome. Unsupervised learning uses data without a target label to explore structure, such as customer segments or lower-dimensional representations.

The evaluation approach changes too. For supervised learning, I'd evaluate predictions against held-out labels using a metric suited to the decision. For clustering, I'd consider separation, stability, interpretability, and whether the groups support a useful action, rather than treating an attractive visualization as proof of success.

Practice the framing, not just the definition

• Likely follow-up: What if only some examples have labels? Explain that semi-supervised learning combines labeled and unlabeled examples, then ask whether the labels are representative and reliable.
• Hands-on task: Take a public retail dataset and write separate problem statements for purchase prediction and customer segmentation. Specify the inputs, expected output, validation approach, and intended user for each.
• Portfolio evidence: Bring a short decision note explaining why your project required prediction rather than segmentation, or vice versa. Include an alternative you rejected.

Avoid claiming that clustering automatically identifies meaningful customer types. A mathematically separated group may reflect spending scale, preprocessing choices, or irrelevant attributes rather than a useful marketing distinction.

Use the data scientist interview question bank to extend the drill: explain your choice, then defend how you'd evaluate it. The business question should determine the learning setup, not your preferred algorithm.

2. How would you handle missing data in a dataset?

“I'd fill missing values with the mean” is an implementation, not a complete answer. Begin by asking what's missing, where it occurs, and how the data was collected.

Model answer: I'd inspect missingness by column, time period, source, and relevant population groups. Then I'd investigate whether values are missing because of a collection failure, an optional field, or a process that makes absence informative. I'd distinguish missing completely at random, missing at random conditional on observed variables, and potentially nonrandom missingness without claiming that inspection alone proves the mechanism.

For a hypothetical shopping dataset with missing ages, I'd compare a simple median-imputation baseline with an approach that also includes a missingness indicator. I'd fit imputation inside the training pipeline and within each training fold, so validation data doesn't influence preprocessing. I'd document the choice and check whether it changes results across customer groups.

Defend the cleaning decision

Likely follow-ups include whether you would drop the column, use a model-based imputer, or ask the data owner to repair the source. Explain that advanced imputation adds assumptions and complexity; it is not automatically better than a transparent baseline.

For a hands-on drill, use pandas to summarize missingness, compare complete and incomplete records, and build a scikit-learn Pipeline with an imputer. Check that the pipeline handles missing values during prediction.

Your portfolio evidence should show the original issue, alternatives considered, validation results, and unresolved limitations. In a hypothetical healthcare dataset, a missing laboratory value might mean a test wasn't ordered, so replacing it without comment could obscure information about the care process.

3. What is overfitting, and how does the bias-variance tradeoff relate to it?

A model performs impressively on training data but disappoints on validation data. Your first move should be diagnosis, not an automatic switch to a more elaborate algorithm.

Model answer: Overfitting happens when a model captures training-specific patterns, including noise, that don't generalize to new examples. Underfitting happens when the model cannot capture important structure. Bias describes systematic error from restrictive assumptions, while variance describes sensitivity to the particular training sample.

A highly flexible decision tree can fit training quirks, while an overly restrictive model can miss useful relationships. I'd inspect training and validation performance using a split that reflects the intended deployment, then investigate leakage or distribution differences before concluding that complexity is the only problem.

Choose a remedy for the diagnosis

• Simplify the model: Constrain tree depth or reduce unnecessary features when flexibility appears excessive.
• Regularize: Compare penalized models when unstable coefficients or overly complex fits are concerns.
• Improve validation: Use time-aware or group-aware splits when observations aren't independent in the way a random split assumes.
• Inspect the data: Check duplicate entities, target-derived features, and information that wouldn't exist at prediction time.

For an additional explanation to rehearse against, use the accompanying video.

Likely follow-up: Would more data fix it? Say that more representative data may help, but it won't repair target leakage or an unsuitable evaluation setup.

For your hands-on task, compare an unconstrained tree with a constrained alternative and plot training and validation performance as complexity changes. Your portfolio evidence should include the split rationale and an unsuccessful experiment, not just the winning model. Explain what you learned and why the final comparison was fair.

4. How do you evaluate a classification model on an imbalanced dataset?

For a hypothetical fraud-review workflow, catching suspicious transactions matters, but so does the workload imposed on reviewers and legitimate customers. The right metric depends on the action attached to the prediction.

Model answer: I wouldn't rely on accuracy alone because it can conceal poor minority-class detection. I'd inspect the confusion matrix, precision, recall, and performance across decision thresholds. Precision describes how many flagged cases are genuinely positive; recall describes how many actual positives the model finds.

I'd use the precision-recall curve to discuss threshold choices and examine PR-AUC as a summary, while still checking performance at the operating threshold. F1 can summarize a balance between precision and recall, but it doesn't encode the organization's actual error costs. I'd also inspect calibration if people will interpret scores as probabilities.

Choose a threshold for the decision people must make, not simply the metric that makes the model look strongest.

Make the trade-off visible

Likely follow-ups: What if the review team has limited capacity? What if missing fraud is more costly than investigating a legitimate transaction? Describe a threshold decision that accounts for those constraints rather than declaring that recall always wins.

For the hands-on drill, compare a baseline classifier with a class-weighted version. Keep any resampling inside training folds, preserve a representative evaluation set, and explain whether stratification is compatible with the required temporal or grouped split.

Your portfolio evidence should include a threshold plot and a recommendation for the intended workflow. Show which errors remain unacceptable and what a human reviewer would do with a flagged case. A performance score without that decision context leaves the most important question unanswered.

5. Explain p-values and the difference between correlation and causation

Give the definition precisely, then explain what you're allowed to conclude. This question is a chance to demonstrate restraint, not just statistical vocabulary.

Model answer: A p-value is the probability, under the null hypothesis and the assumptions of the test, of obtaining a test statistic at least as extreme as the observed one. It isn't the probability that the null hypothesis is true, and it doesn't measure effect size or business importance. I'd report the estimated effect and an appropriate confidence interval alongside the test result.

Correlation describes an association between variables. A causal claim requires a defensible identification strategy, such as a properly designed randomized experiment or an observational design with justified assumptions about confounding and selection. An association alone doesn't establish which variable influences the other.

Rehearse a responsible interpretation

Consider a hypothetical dataset where customers who use a recommendation feature purchase more often. Those customers might already be more engaged, so comparing users with nonusers doesn't isolate the feature's effect.

• Likely follow-up: Does an inconclusive test mean there's no effect? Explain that the available evidence may remain compatible with effects that matter, depending on the interval and study design.
• Hands-on task: Write a null hypothesis, define the effect you want to estimate, choose an appropriate test, and interpret the result without using “proved.”
• Portfolio evidence: Include an uncertainty statement and identify a plausible confounder. If your work is observational, label the result as an association unless you can defend a causal design.

The Kaggle survey synthesis discussed in the preparation brief supports combining practical tool preparation with statistical reasoning. For this drill, the important distinction is between producing an output and defending the conclusion someone might draw from it.

6. Write a SQL query to find the second-highest salary (or top N per group)

Before typing, ask: “Do you mean the second-highest distinct salary, or the employee in the second position?” That clarification determines how ties should behave.

Model answer: For the second-highest distinct non-null salary, I can find the maximum salary below the overall maximum:

SELECT MAX(salary) AS second_highest_salary FROM employees WHERE salary < (SELECT MAX(salary) FROM employees);

This returns a scalar result and produces NULL when there isn't another distinct salary. For grouped ranking, I'd use a window function and specify whether the output should contain salary values or employee records.

Explain ties before choosing a window function

DENSE_RANK() gives equal values the same rank without leaving gaps. RANK() leaves gaps after ties, while ROW_NUMBER() assigns separate positions and needs a deterministic tie-breaker when consistent selection matters. For top-ranked employees within departments, add PARTITION BY department and filter the resulting rank in an outer query.

• Likely follow-ups: What happens with tied salaries, nulls, an empty table, or a department with insufficient distinct values? Explain the expected result before changing the query.
• Hands-on task: Create an employee table containing ties and missing salaries. Test both a distinct-salary result and an employee-level result, then compare the output with your written expectations.
• Portfolio evidence: Keep a query, a description of the table's row-level meaning, and validation checks showing that joins haven't duplicated employees.

The Stack Overflow Developer Survey reports broad use of both SQL and Python, supporting preparation in data retrieval alongside modeling. Extend this drill with the data analyst technical interview questions and answers, especially joins, aggregation, and query debugging.

Correct output is only part of the answer. You should also explain what each returned row represents.

7. How would you design an A/B test to evaluate a new feature?

Start with a decision: should the team release the feature, revise it, or gather more evidence? For a hypothetical checkout change, increased purchase completion might be the objective, but errors and customer friction still matter.

Model answer: I'd define the eligible population, hypothesis, primary metric, and guardrails before launching. Then I'd choose a randomization unit that limits contamination, estimate sample requirements using a meaningful minimum detectable effect and the intended analysis, and set a duration appropriate to usage patterns. I'd verify assignment and instrumentation before interpreting outcomes.

For analysis, I'd estimate the treatment effect and uncertainty using a method suited to the metric and randomization unit. I'd check assignment balance, missing events, and sample-ratio mismatch, then follow the predeclared decision rule. I wouldn't repeatedly inspect a conventional fixed-horizon test and stop whenever the result became favorable.

Practice the failure cases

Likely follow-ups include users switching devices, teams sharing access, or a primary metric improving while a guardrail worsens. State which assumption each situation threatens and what you'd investigate or escalate.

The Intuit internship guidance identifies experimentation and communication among relevant preparation areas. Demonstrate both by explaining an inconclusive result without translating it into either “the feature works” or “the feature failed.”

For your hands-on task, write an experiment plan covering eligibility, assignment, exposure logging, metrics, analysis, and release criteria. Ask a peer to identify ways your plan could produce a misleading conclusion.

Your portfolio evidence can be that plan, even if you've never launched a production experiment. Label it as a proposal or simulation and distinguish design work from observed business impact.

Practical rule: If you can't explain how the experiment could mislead you, your design isn't ready to defend.

8. Walk me through a data project you worked on, from problem to impact

Choose a project you can defend at the level of individual decisions. A modest analysis with trustworthy validation gives you more to discuss than an elaborate notebook you can't explain.

Model answer framework: State the problem and intended user, explain your responsibility, and describe the data limitations. Then cover your baseline, important cleaning or modeling decisions, validation approach, result, and remaining uncertainty. Separate what you personally did from the team's work.

For a student housing-price project, explain why you compared linear regression with gradient boosting, how you prevented leakage, and which errors mattered. If nobody deployed the model, call the result offline validation performance, not business impact.

Bring evidence for the difficult questions

• Likely follow-ups: What failed? What did you change? What would you do with better data? Prepare an honest answer for each.
• Hands-on task: Rebuild the project from a clean environment, rerun the analysis, and check that the saved outputs match your narrative.
• Portfolio evidence: Bring a concise decision log, a reproducible notebook, and a visualization that supports your recommendation.

If you used AI assistance, explain what it generated and how you checked it. The internship guidance on modern AI-assisted workflows supports preparing for verification, privacy, and disclosure questions, not merely faster coding.

Keep prompts, transformations, and validation notes together rather than accepting explanations you can't audit. If you explore ways to reduce AI context switching costs, evaluate the workflow against that same standard.

Use the data scientist interview guide to pressure-test your story. Every claimed result should be traceable to an artifact you can explain.

Data Science Intern Interview Questions: 8-Point Comparison Guide

Interview Question	🔄 Implementation Complexity	Resource Requirements	📊 Expected Outcome	Ideal Use Case	⭐ Key Advantage
Supervised vs. unsupervised learning	🔄 Low; explain concepts and examples	Basic ML vocabulary and evaluation metrics	Clear distinction between labeled prediction and unlabeled pattern discovery	Foundational ML interviews	💡 Demonstrates understanding of how ML problems are framed
Handling missing data	🔄 Moderate; assess missingness before choosing a method	Dataset context, preprocessing tools, and awareness of leakage	A documented strategy such as deletion, imputation, or missingness indicators	Data cleaning and preprocessing discussions	⭐ Shows practical judgment about data quality and bias
Overfitting and the bias-variance tradeoff	🔄 Moderate; explain diagnosis and remedies	Training/validation results and knowledge of regularization or cross-validation	Better generalization through appropriate model and validation choices	Model evaluation and troubleshooting	📊 Connects model complexity to performance on unseen data
Evaluating classification on imbalanced data	🔄 Moderate; select metrics and consider threshold trade-offs	Confusion matrix, precision/recall metrics, and stratified validation	More meaningful evaluation using metrics such as PR-AUC, precision, and recall	Fraud, churn, or medical prediction	⭐ Links model evaluation to the costs of false positives and negatives
P-values; correlation vs. causation	🔄 Moderate; define terms and identify confounding	Statistical concepts, confidence intervals, and causal reasoning	Responsible interpretation of significance and relationships	Statistics, experimentation, and analytical interviews	💡 Helps avoid unsupported causal claims
SQL for second-highest salary or top N per group	🔄 Moderate; write and explain a query that handles ties	SQL aggregates, subqueries, and window functions	Correct ranking or selection, with tie behavior made explicit	SQL coding screens and analytics tasks	⚡ Tests practical querying skills with verifiable results
Designing an A/B test	🔄 High; plan the experiment and analysis end to end	Hypothesis, metrics, sample-size estimate, randomization, and statistical test	Evidence to support a product decision while monitoring guardrails	Product analytics and feature evaluation	📊 Combines statistical rigor with business impact
Walking through a data project	🔄 Moderate; structure a concise end-to-end narrative	Project details, individual contributions, validation, and measurable results	A clear account of the problem, approach, challenges, and impact	Behavioral-technical interviews	⭐ Highlights ownership, communication, and applied skills

Turn Preparation into Interview-Ready Evidence

Mastering these questions is the starting point. Build a portfolio project that demonstrates your reasoning from data collection through validation, then create a short evidence sheet for each important decision. Record the business objective, alternatives considered, chosen metric, observed result, and limitation you'd address next.

Keep the evidence proportionate to your experience. An intern candidate doesn't need to claim responsibility for company strategy or a production launch. You do need to explain your contribution, recognize when an assumption is weak, and know when to ask a teammate or supervisor for guidance.

Build a rehearsal loop you can repeat

Practice each question as a concise response and as a deeper explanation with a worked example. The short version should establish the answer and its main qualification; the deeper version should reveal your assumptions, validation method, and decision logic. Don't memorize identical wording, because a follow-up can change the problem.

• Check technical precision: Define the target, population, row-level meaning, metric, or hypothesis before discussing tools.
• Check implementation: Run the query or notebook, inspect edge cases, and verify that preprocessing respects the validation boundary.
• Check interpretation: Distinguish observed results from speculation, association from causation, and offline performance from business impact.
• Check communication: Explain what someone should do with the result and what evidence might change your recommendation.

Use a recording or a practice partner to find the points where you become vague. If you say you “cleaned the data,” name the defect and the rule you applied. If you say a model was “better,” identify the comparison, evaluation setup, and trade-off.

Prepare for pressure without hiding uncertainty

Interview Pilot's searchable question bank and AI Mock Interview sessions offer ways to rehearse unfamiliar prompts and practice pacing. Use them to test whether you can explain your own work rather than substitute generated language for understanding. If you consider live interview support, follow the employer's rules and disclose assistance where required.

In the interview itself, clarify assumptions before committing to an approach. If you're unsure, explain what you know, what you'd check, and how the answer depends on the result. That's more credible than confidently supplying an unsupported conclusion.

Choose a question today and connect it to an artifact from your portfolio. Rehearse until you can explain the decision, demonstrate the work, and describe its limits without reading your notes. Sound reasoning plus inspectable evidence gives the interviewer something concrete to evaluate.

---

Interview Pilot offers guided AI Mock Interview practice, a searchable question bank, and real-time suggested answers for live online interviews. Visit Interview Pilot to rehearse data science intern interview questions, practice follow-ups, and refine how you explain your projects, while following any rules your interviewer sets on assistance.