Data science interviews have changed. A few years ago most of the questions were definitions of statistics terms. Today employers test whether you can get data with SQL, clean and explore it in pandas, reason about statistics and experiments, build a sensible model, and explain the result to people who do not write code. This guide gives you 50 data science interview questions and answers that follow that structure.
Every answer starts with a short, direct response you can say aloud, followed by detail, a table or working code. The SQL examples were run in SQLite and the Python examples were run before they were added, so the printed output under each sample is the real result. Formulas are written in words, so nothing depends on an image. Where a topic needs more depth, the answer points you to the Statistics, Machine Learning or Python interview pages.
The guide has eight parts: 8 questions on basics and workflow, 9 on SQL, 5 on pandas, 8 on statistics essentials, 4 on machine learning essentials, 7 on A B testing, 4 case studies and 5 project and behavioural questions. Freshers can start at the top. Experienced candidates should go straight to experimentation, case studies and project questions.
| Section | Questions |
|---|---|
| Data Science Basics and Workflow (Freshers) | Q1 to Q8 |
| SQL for Data Science (Freshers and Intermediate) | Q9 to Q17 |
| Python and pandas for Data Science (Freshers and Intermediate) | Q18 to Q22 |
| Statistics Essentials for Data Science (Intermediate) | Q23 to Q30 |
| Machine Learning Essentials for Data Science (Intermediate) | Q31 to Q34 |
| A B Testing and Experimentation (Intermediate and Experienced) | Q35 to Q41 |
| Case Study Questions (Experienced) | Q42 to Q45 |
| Project and Behavioural Questions (All Levels) | Q46 to Q50 |
Freshers are usually asked how data science work is organised and how it differs from neighbouring roles. Answer with the full project flow in mind, from the business question to a monitored result.
Data science uses statistics, programming and domain knowledge to answer business questions and build predictive models from data. Data analytics focuses on describing what happened and why, usually with SQL and dashboards. Machine learning engineering focuses on deploying and running models reliably in production. In small teams one person often does all three.
| Role | Main question | Typical tools | Typical output |
|---|---|---|---|
| Data analyst | What happened, and why? | SQL, Excel, Power BI, Tableau, basic Python | Reports, dashboards, insights |
| Data scientist | What will happen, and what should we do? | Python, SQL, statistics, scikit learn | Models, experiments, recommendations |
| Machine learning engineer | How do we run this model reliably at scale? | Python, cloud services, pipelines, monitoring | Deployed and monitored model services |
A typical project moves through problem definition, data collection, cleaning, exploratory analysis, feature engineering, modelling, evaluation, deployment and monitoring. The steps repeat, because results from modelling often send you back to the data. The first step matters most, since a model built for the wrong question has no value.
Structured data fits rows and columns with a fixed schema, such as a sales table. Semi structured data has tags or keys but no rigid schema, such as JSON and XML files. Unstructured data has no predefined format, such as free text, images, audio and video. Each needs different storage and processing tools.
Exploratory data analysis is looking at the data before modelling to understand its shape, quality and patterns. Start with the number of rows and columns, the data types, missing values, duplicates, and summary statistics. Then look at distributions, outliers, and relationships between features and the target.
The maximum spend is far above the rest in the printed summary, which is the kind of outlier to investigate before modelling.
Check completeness, uniqueness, validity, consistency and freshness. Look for missing values, duplicate keys, values outside a sensible range, categories spelled in different ways, dates that do not make sense, and totals that do not match the source system. Write these checks as code so they run again each time the data refreshes.
ETL extracts data, transforms it on a separate processing server, and then loads the result into the warehouse. ELT loads the raw data into the warehouse first and transforms it there using the warehouse engine. ELT is common with modern cloud warehouses because storage is cheap and the raw data stays available for new questions.
Start from the decision the metric will support. A good metric is tied to the business goal, can be measured reliably, is hard to game and moves when the real outcome moves. Pair a main metric with guardrail metrics that catch harm, for example pairing conversion with refund rate.
Most data scientists use Python or R for analysis and modelling, SQL for getting data, Jupyter notebooks or an editor for development, and Git for version control. Visualisation tools such as Power BI or Tableau help with sharing results, and cloud platforms such as AWS, Azure or Google Cloud host larger workloads.
Almost every data science interview includes a live SQL question. The examples below were run in SQLite, and the same ideas work in MySQL, PostgreSQL and SQL Server with minor changes in syntax.
WHERE filters individual rows before grouping happens, and HAVING filters the groups after aggregation. You cannot use an aggregate such as COUNT or AVG inside WHERE. Use WHERE to reduce the data early, which is faster, and HAVING for conditions on the grouped result.
An inner join returns only rows that match in both tables. A left join returns all rows from the left table and the matches from the right, with nulls where there is no match. A right join does the reverse, and a full outer join returns all rows from both. A cross join pairs every row with every row.
The left join with a null check is the standard way to find rows in one table that have no match in another.
A window function calculates a value across a set of related rows without collapsing them into one row, as GROUP BY does. Use ROW_NUMBER, RANK or DENSE_RANK with PARTITION BY and ORDER BY to rank rows inside each group, then keep rank 1 in an outer query.
Rank the distinct salaries with DENSE_RANK in descending order and pick rank 2. DENSE_RANK is safer than ROW_NUMBER because tied salaries share a rank and do not hide the next value. A simpler version uses a subquery with MAX of the salaries below the overall maximum.
Group by the columns that define a duplicate and keep only groups with a count above one to find them. To remove them, keep one row per group, for example the row with the smallest row id, and delete the rest. Always run the select version first so you see what will be deleted.
A subquery is a query inside another query, and a common table expression, or CTE, names a subquery with WITH so it reads top to bottom. Use a CTE to build monthly totals, then use the LAG window function to bring in the previous month and calculate the percentage change.
NULL means unknown, so it is not equal to anything, including another NULL. Use IS NULL and IS NOT NULL to test for it. COUNT of a column ignores NULLs, while COUNT of star counts every row. Use COALESCE to replace NULL with a default value in a result.
The last query returns 0 because a comparison with NULL is never true. The correct test is IS NULL.
UNION combines the results of two queries and removes duplicate rows, which needs extra work to sort or hash the rows. UNION ALL combines them and keeps every row, so it is faster. Use UNION ALL unless you specifically need duplicates removed. Both need the same number of columns with compatible types.
An index is a separate sorted structure, usually a B tree, that lets the database find rows without scanning the whole table. It speeds up filters, joins and sorts on the indexed columns, but it takes storage and slows down inserts and updates. Index the columns you filter and join on most often.
These questions focus on the pandas work that fills a data scientist day. For core Python topics such as decorators, generators and the GIL, see the Python interview questions page.
Use drop_duplicates to remove repeated rows, optionally on a subset of columns, and astype or the to_datetime and to_numeric functions to fix types. Set errors to coerce so that bad values become missing instead of stopping the code, then inspect those missing values on purpose.
Both summarise data by categories. The groupby method returns a long format result with one row per group, and pivot_table arranges one category across the rows and another across the columns, like an Excel pivot. Use pivot_table when you want a cross tab for a report, and groupby when you will keep processing the result.
Set the date column as the index, then use rolling with a window size for a moving average, and resample with a frequency such as weekly or monthly to aggregate over time. Rolling averages smooth short term noise so that the trend is easier to see.
The most common problem is a many to many join, where the join key repeats in both tables and the number of rows multiplies, which quietly inflates totals. Check key uniqueness before merging, use the validate argument to enforce the expected relationship, and compare row counts and totals after the merge.
Read it in chunks with the chunksize argument and aggregate each chunk, load only the columns you need with usecols, use smaller data types such as category and int32, or convert the file to a columnar format such as Parquet. For data far beyond one machine, use a distributed tool such as Spark.
These are the statistics ideas that data science interviews return to most often. Each answer is short on purpose. A fuller set with worked examples is on the Statistics interview questions page.
A population is the full group you want to understand, and a sample is the part of it you actually measure. Descriptive statistics summarise the sample. Inferential statistics use the sample to draw conclusions about the population, with a measure of uncertainty, through estimates, confidence intervals and hypothesis tests.
A p value is the probability of seeing a result at least as extreme as the one observed, if the null hypothesis is true. A small p value is evidence against the null hypothesis. It is not the probability that the null hypothesis is true, and it does not measure the size of an effect.
A common threshold is 0.05, but it is a convention. Decide the threshold before you run the test, and report the effect size along with the p value.
A Type I error is rejecting a true null hypothesis, a false alarm, and its probability is the significance level alpha. A Type II error is failing to reject a false null hypothesis, a missed effect, with probability beta. Power is 1 minus beta, the chance of detecting a real effect, and a common target is 80 percent.
| Decision | Null hypothesis is true | Null hypothesis is false |
|---|---|---|
| Reject the null hypothesis | Type I error (false positive) | Correct decision, this is power |
| Fail to reject the null hypothesis | Correct decision | Type II error (false negative) |
The central limit theorem says that the distribution of sample means approaches a normal distribution as the sample size grows, whatever the shape of the original data, provided the variance is finite. It matters because it lets us use normal based confidence intervals and tests on averages, even when the raw data is skewed.
A 95 percent confidence interval is a range calculated so that, if you repeated the study many times, about 95 percent of the intervals built this way would contain the true value. It does not mean there is a 95 percent chance the true value lies in this one interval. A narrower interval means a more precise estimate.
The normal distribution is a symmetric bell shaped distribution described by its mean and standard deviation. It is common in theory because of the central limit theorem, but many real variables are not normal. A z score is the number of standard deviations a value lies from the mean. It is not limited to a fixed range.
The rule of thumb that about 99.7 percent of values lie within three standard deviations applies to normal data only. It is often used to flag outliers, but it is not a limit on the z score.
Correlation means two variables move together. Causation means a change in one produces a change in the other. A correlation can come from a third factor that drives both, from chance, or from reverse causation. A randomised experiment is the strongest way to show causation, because it removes other explanations.
Example to use in an interview: ice cream sales and drowning incidents both rise in summer. Heat drives both, so neither causes the other.
Use the mean for roughly symmetric data without extreme values, since it uses every value. Use the median when the data is skewed or has outliers, because it is not pulled by a few extreme values. Income and house prices are typical cases where the median describes a typical value better.
Data science interviews include machine learning, but usually test judgement more than algorithm detail. These answers are brief. The Machine Learning interview questions page covers each topic in depth.
Begin with a simple baseline, such as predicting the most common class, the average, or a basic linear model. The baseline tells you whether a complex model adds real value, and it often catches data problems early. If a sophisticated model only beats the baseline by a hair, the extra complexity is rarely worth it.
Ask what each kind of mistake costs. If missing a positive case is expensive, as in fraud or disease screening, focus on recall. If false alarms are expensive, focus on precision. For ranking quality use ROC AUC or the precision recall curve, and for forecasts use an error measure such as MAE in business units.
Compare training performance with validation performance. If training is much better, the model is memorising the data. Use cross validation, simplify the model, add regularisation, reduce noisy features or get more data. Also check for data leakage, which can make a model look better than it is.
Use plain language and a concrete example. Show the few factors that pushed the prediction up or down, using coefficients for linear models or permutation importance and SHAP values for complex ones. Tell them how reliable the model is and where it should not be trusted, instead of showing technical metrics alone.
Experiment design is one of the most common areas where interviewers separate strong candidates from average ones. Product and e commerce companies in particular spend a lot of time on it.
An A B test randomly splits users into a control group that sees the current version and a treatment group that sees the change, then compares a chosen metric between them. For a conversion rate, use a two proportion z test or a chi square test, and report the difference, its confidence interval and the p value.
Fix the baseline rate, the smallest effect worth detecting, the significance level and the power before you start. A common approximation for a conversion rate with 5 percent significance and 80 percent power is about 16 times p times (1 minus p), divided by the squared difference, users per group. Smaller effects need far more users.
The quick rule gives a slightly lower number than this exact formula. Halving the effect you want to detect roughly quadruples the number of users you need. That is why tiny improvements can take weeks to confirm.
Sample ratio mismatch means the number of users in each group differs from the split you planned, for example 50 to 50, by more than chance allows. It signals a bug in assignment or logging, and the results are not trustworthy until it is fixed. Check it with a chi square test on the group counts.
Peeking means checking the results repeatedly and stopping as soon as the p value drops below 0.05. Each look is another chance for a false positive, so the real error rate becomes much higher than 5 percent. Decide the sample size in advance and wait for it, or use sequential testing methods designed for repeated looks.
Testing many metrics or segments at once raises the chance that at least one looks significant by luck. Control it by naming one primary metric in advance, and by adjusting the threshold for the others, for example with the Bonferroni correction, which divides alpha by the number of tests, or the Benjamini Hochberg method.
The primary metric is the single measure that decides whether the experiment succeeded, such as conversion rate. Guardrail metrics are measures that must not get worse, such as page load time, refund rate or unsubscribe rate. A change that lifts the primary metric but breaks a guardrail should not ship.
Use a quasi experimental method. A difference in differences design compares the change over time in a treated group with the change in a similar untreated group. Matching, synthetic control and regression with careful controls are other options. All of them rely on assumptions, so state the assumptions and the limits of the conclusion.
Case questions are open on purpose. The interviewer wants to see how you structure a vague problem, what you ask first and how you reach a recommendation. Say your steps aloud, and state assumptions as you go.
First confirm that the drop is real by checking data pipelines and tracking, then compare it with the same week in earlier periods. Break the drop down by city, platform, customer type, restaurant and time, find which segment explains most of it, and test the likely causes for that segment, such as an outage, a price change, a competitor offer or supply shortage.
In this made up table, one segment explains most of the total decline, so that is where the investigation should go next.
What the interviewer is listening for: You check the data before the business, you segment to find where the problem is, and you finish with a testable explanation.
Start by defining churn, the prediction window and the action the business will take. Build features from past behaviour such as usage, payments and support contacts, using only data available at the prediction date. Split by time, compare against a simple baseline, choose a metric that matches the cost of a retention offer, and plan how the scores will be used and monitored.
What the interviewer is listening for: You start from the decision and the data timeline, not from the algorithm.
Link the feature to a business goal, choose one primary metric, add guardrail metrics, and run a randomised experiment if you can. Define the target group, the minimum change worth detecting and the test duration in advance. After the test, look at segments to see who benefits, and decide whether the gain justifies the cost of running the feature.
What the interviewer is listening for: You use an experiment, one clear primary metric and guardrails against harm.
Start with simple baselines, such as the last value, the same period last year and a moving average, and measure them on a time based holdout. Group products by pattern, since stable, seasonal and intermittent items need different methods. Add a more advanced model only if it beats the baseline by enough to matter, and report forecast error in business units.
On data with a yearly pattern, the seasonal baseline wins easily. Any complex model has to beat it to earn its place.
What the interviewer is listening for: You build and respect baselines, validate on later data, and judge a model by business error.
Interviewers use these questions to find out how you work with people, handle imperfect data and take ownership. Use real examples from your own projects, and prepare them in advance.
Tell it in five parts: the business problem, the data you had, what you did and why, the result with a number, and what you would change. Keep your own contribution clear, and be ready for questions on any choice you made. Choose a project you can explain in about three minutes.
What the interviewer is listening for: Clear ownership, honest numbers and the ability to defend each decision.
Pick a real case and describe the specific problems, such as missing values, inconsistent categories or duplicate records. Explain how you found them, what you decided and why, and what effect your choices had on the result. Mention that you documented your assumptions so others could review them.
What the interviewer is listening for: You check data before trusting it, and you can explain trade offs.
Start with the decision or answer, then give the two or three facts that support it, using simple charts and plain words. Leave out method detail unless asked, state the uncertainty honestly, and end with a clear recommendation and next step. Check afterwards that the audience understood what to do.
What the interviewer is listening for: You lead with the answer and adapt the message to the listener.
Listen first to understand what they disagree with, then check whether they know something you missed. Show your data and method openly, test their point where possible, and agree on how to resolve it, for example with an additional cut of the data or an experiment. Be willing to change your view if the evidence supports it.
What the interviewer is listening for: You stay open to being wrong and settle disagreements with evidence.
Choose a real, modest mistake, state it plainly, say how you found it and how you told the people affected. Then explain the specific process change you made, such as a review step, a data check or a test, so it would not happen again. Interviewers value honesty and learning over a perfect record.
What the interviewer is listening for: You take responsibility without excuses and you improved a process.
Most data science interviews have a screening call, a SQL or Python test, a statistics and machine learning round, a case study or take home task, and a conversation about your past projects. Product companies add experimentation questions, and larger teams add a system design or deployment round.
Learn SQL and pandas well, because they decide most first rounds. Then revise statistics basics, one end to end machine learning project and how to explain it. Practise answering aloud. Having two projects you can defend in detail counts for more than a long list of tools.
Yes. Almost every data science role needs you to pull and join your own data, and many first round tests are SQL only. You should be comfortable with joins, grouping, window functions and common table expressions, and able to explain what each query does and why.
Analyst interviews lean toward SQL, dashboards and business metrics. Data science interviews add statistics, experiment design and machine learning, and expect you to build and validate models. The two overlap heavily at junior level, so read the job description for the exact weight.
Prepare two or three projects that you can explain from the business problem to the result. Choose ones where you made real decisions about data, modelling and evaluation. Be honest about what you did yourself, and be ready to discuss what went wrong and what you would change.
Use this plan if you have about a month before your interview.
| Week | Focus | What to do |
|---|---|---|
| Week 1 | SQL: joins, grouping, window functions and CTEs | Run every SQL example in this guide, then write ten of your own queries on a sample database. |
| Week 2 | Python, pandas and exploratory analysis | Take one public dataset, clean it and write down five findings. Practise the pandas section. |
| Week 3 | Statistics, machine learning and A B testing | Work through the statistics and experiment sections, then build one baseline model end to end. |
| Week 4 | Case studies, projects and mock interviews | Practise two case questions aloud, write your three minute project story and take a mock interview. |
If you want to practise these questions with a trainer and build projects you can talk about in interviews, you can book a free demo class for the Prwatech Data Science course. It covers Python, SQL, statistics and machine learning with hands on work.
Contact the learning team for current batch dates and fees.
Written by Mithun Ray, data engineering trainer at Prwatech. Reviewed by Avishekh Verma. Last updated October,2026.