Data Science Interview Questions and Answers for Freshers and Experienced

Data science uses statistics, programming and machine learning to extract insight from data and often to build predictive models. Data analytics focuses more on describing what happened and why, using SQL, spreadsheets and dashboards. In practice the roles overlap: an analyst might explain why orders fell last month, while a data scientist might build a model to forecast next month's orders. Job titles vary a lot between companies, so read the job description carefully.

The mean is the arithmetic average, while the median is the middle value when data is sorted. Use the median when data is skewed or has outliers, because a few extreme values pull the mean but barely move the median. Salaries are the classic example: a handful of very high earners can lift the mean well above what a typical person earns. For roughly symmetric data without outliers, the mean is fine and easier to work with mathematically.

A population is the full group you care about, such as all UPI users in India, while a sample is the subset you actually observe. Sampling bias happens when the sample does not represent the population, so conclusions do not generalise. Surveying only metro users about a feature meant for smaller towns is a classic example. Random sampling reduces bias, and stratified sampling ensures key groups, like regions or age bands, are fairly represented.

A normal distribution is a symmetric, bell-shaped distribution defined by its mean and standard deviation. About 68 percent of values fall within one standard deviation of the mean, about 95 percent within two and about 99.7 percent within three. It matters because many statistical tests and confidence intervals assume normality, often through the central limit theorem. Real data, like income or app session length, is frequently skewed, so check before you assume.

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 population, as long as samples are independent and the population has finite variance. It is why we can build confidence intervals and run t-tests on averages even when raw data is skewed. A common rule of thumb is a sample size of 30 or more, but heavily skewed data may need far more.

A p-value is the probability of seeing results at least as extreme as the ones observed, assuming the null hypothesis is true. A small p-value, below a threshold such as 0.05 chosen in advance, means the data would be surprising if there were no real effect, so you reject the null. A p-value is not the probability that the null hypothesis is true, and it says nothing about how large or useful the effect is.

A type I error is a false positive: rejecting the null hypothesis when it is actually true, such as concluding a new feature works when it does not. Its probability is the significance level, alpha. A type II error is a false negative: failing to detect an effect that really exists. Its probability is beta, and statistical power equals 1 minus beta. Lowering alpha reduces false positives but, for the same sample size, increases the risk of missing real effects.

A confidence interval is a range of values that is likely to contain the true population parameter, built from sample data. A 95 percent confidence interval means that if you repeated the sampling 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. Wider intervals signal more uncertainty, usually from small samples or noisy data.

Correlation means two variables move together; causation means one actually changes the other. Ice cream sales and drowning cases both rise in summer, but heat drives both. Confounding variables, reverse causation and coincidence can all create correlation without causation. To claim causation, you need a randomised experiment such as an A/B test, or careful causal methods like difference-in-differences when experiments are not possible.

Start with a clear hypothesis and one primary metric, such as checkout conversion. Decide the randomisation unit (usually the user), calculate the sample size needed for the smallest effect worth detecting, and fix the test duration in advance, ideally covering full weekly cycles. Randomly split users into control and treatment, check the split is balanced, then analyse with a suitable test. Also track guardrail metrics, like app crashes or refunds, so a win on one metric does not hide damage elsewhere.

Four things drive sample size: the baseline rate or variance of the metric, the minimum detectable effect, the significance level and the desired power. Smaller effects need much larger samples; roughly, halving the effect you want to detect needs about four times the users. Noisier metrics also need more data. In practice, if the required sample would take months, test a bolder change or pick a more sensitive metric instead of running an underpowered test.

EDA (exploratory data analysis) is the first look at a dataset to understand its structure, quality and patterns before modelling. I check the number of rows and columns, data types, missing values, duplicates, summary statistics and distributions, then relationships between key variables using plots and correlations. I also sanity-check against reality: negative ages or orders dated in the future signal data quality issues. Good EDA often answers half the business question before any model is built.

First understand why values are missing or extreme, because the cause decides the fix. For missing data, you can drop rows if few are affected, impute with the median or mode, use model-based imputation, or add a flag column. For outliers, check whether they are errors (a typo in a price) or real but rare (a bulk corporate order). Fix or remove errors, but keep real extremes and consider median-based statistics or capping instead.

Use a window function to rank customers within each city, then filter the rank.

SELECT city, customer_id, total_spend
FROM (
  SELECT city, customer_id, SUM(amount) AS total_spend,
         DENSE_RANK() OVER (PARTITION BY city ORDER BY SUM(amount) DESC) AS rnk
  FROM orders
  GROUP BY city, customer_id
) ranked
WHERE rnk <= 3;

DENSE_RANK keeps ties, so a city may return more than three rows. Use ROW_NUMBER if you need exactly three.

WHERE filters individual rows before grouping, while HAVING filters groups after aggregation. To find cities with more than 1,000 orders in 2026, you filter the order date with WHERE, group by city, then keep groups with HAVING COUNT of orders above 1,000. You cannot use an aggregate like SUM inside WHERE. Filtering early with WHERE also reduces the data the database must group, which is usually faster.

Group by city and aggregate, then sort for readability.

import pandas as pd

orders = pd.read_csv("orders.csv")
aov = (orders.groupby("city")["amount"]
             .mean()
             .sort_values(ascending=False)
             .reset_index(name="avg_order_value"))

Before trusting the result, check for duplicate order IDs, missing amounts and cancelled orders, which can distort the average. Mention merge for joining a customers table, and that agg lets you compute several statistics at once.

Start from the question and the data, not the algorithm. Identify the target (category, number or none), the data size and type, and whether stakeholders need to understand the model. Begin with a simple, explainable baseline such as linear or logistic regression, then try tree-based models like gradient boosting if accuracy matters more. Compare on a proper validation split with a metric tied to the business cost. Our machine learning interview questions cover the algorithms in depth.

Simpson's paradox is when a trend that appears in several groups reverses or disappears when the groups are combined. It usually happens because a hidden variable is unevenly distributed across groups. For example, a new app version might raise conversion for both Android and iOS users separately, yet overall conversion falls because more low-converting users happened to upgrade. The lesson: always segment key metrics before drawing conclusions from totals.

Peeking means checking results repeatedly and stopping the test as soon as it looks significant. Each look is another chance for random noise to cross the threshold, so the real false positive rate rises well above the 5 percent you planned. Fix it by setting the sample size and duration in advance, or by using sequential testing methods designed for repeated looks. A related trap is testing many metrics at once; corrections such as Bonferroni or Benjamini-Hochberg help there.

For simple models, coefficients or tree feature importances give a first view. For complex models, SHAP values show how much each feature pushed an individual prediction up or down, and partial dependence plots show average effects. Explain that these show association within the model, not causation in the real world. In regulated areas like lending, explainability is often a requirement, which is one reason simpler, explainable models remain common in lending.

Lead with the recommendation and the business impact, then give the evidence, then the caveats. Replace jargon with plain words: say "we are fairly confident the new flow lifts sign-ups by 2 to 4 percent" instead of quoting a p-value. Use one clear chart per point and state what decision you need from them. I always prepare a one-slide summary, because senior leaders often read nothing else.

Generative AI speeds up routine tasks: writing SQL and pandas code, summarising EDA, drafting reports and extracting structured data from text such as reviews or support tickets. It also adds new work, like building features from embeddings and evaluating LLM outputs. The core skills matter more, not less: framing the right question, checking data quality and judging whether a result is real. Tools change fast, so focus on judgement that stays useful.

Treat AI output like code from a new teammate: useful, but unverified. Check the query logic against the schema, run it on a small sample where you know the answer, compare totals with a trusted dashboard and look for silent errors such as wrong join keys that duplicate rows. LLMs can also hallucinate column names or statistics. Never paste sensitive customer data into tools your company has not approved.

First, confirm the drop is real: check for tracking bugs, delayed data pipelines or a changed metric definition. Then segment by platform, app version, city, acquisition channel and new versus returning users to see where the drop sits. Check external factors like a holiday, a cricket final or a competitor campaign, and internal ones like a release or outage. Once the segment is clear, form a hypothesis, test it with data and recommend a fix or monitoring step.

Define the goal first: new users, more transactions per user or retention. Run it as a randomised experiment if possible, with a holdout group that does not see the offer. Track the primary metric, cost per incremental transaction and guardrails like fraud attempts and refund rates. Watch what happens after the offer ends, because cashback can pull forward usage that would have happened anyway. Success means incremental value exceeds the cost.

Not automatically: statistical significance only says the effect is probably real, not that it is worth it. Compare the lift, and its confidence interval, with the cost of building and maintaining the change and any risk to guardrail metrics. With very large samples, even tiny effects become significant. A 0.1 percent lift on a high-volume payments flow might be valuable; on a low-traffic page it probably is not. The decision is a business call informed by the data.

Clarify what decision the model will drive, for example which customers get a retention call, and how churn is defined. Pull the data available at prediction time only, build a quick logistic regression or gradient boosting baseline and validate it on a later time period. By Friday, share a working model with its precision at the top of the list, known limitations and next steps. Shipping an honest, simple model beats a polished one nobody can use.

Start by clarifying the forecast level (store, product, hour) and how the forecast is used, such as stocking or staffing. Use historical orders with features like day of week, time of day, festivals, weather, promotions and local events. Begin with a seasonal naive baseline, then try gradient boosting or time-series models, validating on later weeks only. Measure error with MAE or MAPE per product group, and treat new products separately since they have no history.