4.1
Descriptive statistics
The first thing you reach for when you see a new dataset
Must-know

Before building any model, you need to understand your data. Interviewers frequently open ML system design rounds with "you have this dataset — how would you approach it?" The expected first answer is always exploratory data analysis, and descriptive statistics are the tools of EDA. Get these wrong and the interviewer loses confidence in your engineering judgment before the real questions even start.

Beyond EDA, these concepts appear in technical depth too: PCA requires the covariance matrix, normalisation decisions require understanding mean and variance, and model evaluation often involves comparing distributions of predictions vs actuals.

Descriptive statistics are summaries. Instead of looking at 1 million data points, you reduce them to a handful of numbers that capture the most important properties: where is the data centred (mean/median), how spread out is it (variance/std), how is it shaped (skewness/kurtosis), and how do different features relate to each other (covariance)?

Think of them as a "health check" for your data — you run these before any modelling to catch problems: skewed distributions, outliers, correlated features, missing patterns.

Measures of centre — mean vs median
Mean: μ = (1/n) · Σ xᵢ ← sum divided by count Median: middle value when sorted ← 50th percentile

The mean is the "balance point" of the distribution — it minimises the sum of squared deviations. The median minimises the sum of absolute deviations. The key difference is sensitivity to outliers:

Mean — use when
Data is roughly symmetric, no extreme outliers. Example: heights of people. Affected heavily by a single extreme value — one billionaire raises the "average" income of a room dramatically.
Median — use when
Data is skewed or has outliers. Example: house prices, income distributions. The median income is far more representative than the mean income in a country with extreme wealth inequality.
Interview signal: when asked "how would you summarise this feature?" — immediately ask about the distribution shape. If skewed → median. If symmetric → mean. This shows statistical maturity.
Variance & standard deviation
Variance: σ² = (1/n) · Σ (xᵢ - μ)² = E[(X - μ)²] = E[X²] - (E[X])² ← useful alternative form Std dev: σ = √σ² ← same units as the data

Variance measures how spread out values are around the mean. Squaring the deviations makes all terms positive and penalises large deviations more. Standard deviation is just variance back in the original units — easier to interpret.

  • Small variance → values cluster tightly around the mean
  • Large variance → values are spread widely
  • Variance of a constant = 0
  • Adding a constant to all values doesn't change variance; multiplying by c scales variance by c²
  • In ML: feature normalisation (subtract mean, divide by std) puts all features on the same scale — essential for gradient-based models and distance-based models (KNN, SVM)
Covariance & the covariance matrix
Cov(X, Y) = E[(X - μₓ)(Y - μᵧ)] = E[XY] - E[X]·E[Y] Cov(X, X) = Var(X) ← covariance of a variable with itself = variance Sign interpretation: Cov > 0 → X and Y tend to increase together Cov < 0 → X tends to increase when Y decreases Cov = 0 → no linear relationship (but could still be non-linear)

For a dataset with d features, the covariance matrix Σ is a d×d symmetric matrix where entry (i,j) = Cov(Xᵢ, Xⱼ):

Σ = (1/n) · XᵀX (when X is mean-centred, shape: d×d) Diagonal entries: Var(Xᵢ) — variance of each feature Off-diagonal (i,j): Cov(Xᵢ, Xⱼ) — how features i and j co-vary

The covariance matrix is central to PCA — eigenvectors of Σ are the principal components, eigenvalues are the variance along each component. Large off-diagonal values mean features are correlated and potentially redundant.

Skewness & kurtosis — the shape of the distribution
Skewness — asymmetry
Skewness = 0 → symmetric (Gaussian)
Skewness > 0 → right-skewed: long tail on the right, mean > median (e.g. income, house prices)
Skewness < 0 → left-skewed: long tail on the left, mean < median

Highly skewed features often benefit from log-transform before feeding into linear models.
Kurtosis — tail heaviness
Measures how heavy the tails are vs a Gaussian (kurtosis = 3).
High kurtosis (leptokurtic): heavy tails, more extreme outliers — common in financial data.
Low kurtosis (platykurtic): light tails, fewer extremes.

Heavy-tailed data means outliers are more frequent than Gaussian would predict.
Interview Q & A
Q: You're given a new dataset. Walk me through how you'd do initial exploratory data analysis.
A: First, check shape and types — how many samples, how many features, what are the dtypes. Then for each numerical feature: compute mean, median, std, min, max and check for outliers (values beyond 3σ). Compare mean vs median to detect skew — if they differ a lot, the feature is skewed and may need a log-transform. Compute the covariance matrix or correlation matrix to identify highly correlated features, which may cause multicollinearity. Check for missing values and their pattern. For categorical features, check cardinality and class distribution. Finally, look at the target variable distribution — is it imbalanced? This analysis drives every downstream decision: normalisation, encoding, feature selection, and model choice.
4.2
Bias-variance tradeoff
The core tension in every modelling decision
Must-know

This is the single most important concept in applied ML. Every modelling decision — choosing model complexity, adding regularisation, collecting more data, applying dropout — is a move along the bias-variance spectrum. If you can't explain the tradeoff clearly, interviewers will question your understanding of why models fail and how to fix them.

It's asked directly ("explain bias-variance tradeoff") and indirectly ("why is your model overfitting?", "when would you use L2 regularisation?", "how would you fix underfitting?"). All are the same question in disguise.

Bias is the error from wrong assumptions. A linear model fitting a sine wave has high bias — it's systematically wrong no matter how much data you give it. It's not paying attention to the data closely enough.

Variance is the error from being too sensitive to the training data. A 100-layer decision tree memorises every training point but fails completely on new data. It's paying too much attention — to noise.

The tradeoff: making a model more complex (lower bias) almost always makes it more sensitive to the training data (higher variance). The sweet spot is a model complex enough to capture real patterns but not so complex it captures noise.

The decomposition

For any model, the expected prediction error at a point x can be decomposed as:

E[(y - ŷ)²] = Bias²(ŷ) + Variance(ŷ) + Irreducible noise where: Bias(ŷ) = E[ŷ] - f(x) ← how wrong the average prediction is Variance(ŷ) = E[(ŷ - E[ŷ])²] ← how much predictions vary across datasets Irreducible = Var(ε) ← noise in the data itself — cannot be reduced

The irreducible noise is a floor — even a perfect model cannot go below it. Your job is to minimise Bias² + Variance.

High bias (underfitting)
Symptoms: Training error is high Validation error ≈ training error (both bad) Model is "too simple" for the data Examples: Linear regression on non-linear data Shallow decision tree on complex patterns Too much regularisation (λ too high) Fixes: Use a more complex model Add more features / feature engineering Reduce regularisation Train longer (for neural nets)
High variance (overfitting)
Symptoms: Training error is low Validation error >> training error (large gap) Model "memorises" training data Examples: Deep unpruned decision tree Neural net trained too long without regularisation High-degree polynomial on few data points Fixes: Regularisation: L1/L2 (add penalty for large weights) Dropout: randomly zero activations during training Early stopping: stop when validation loss stops improving More training data (reduces variance, doesn't fix bias) Simpler model / fewer parameters Cross-validation: get honest estimate of generalisation
The "more data" rule — critical nuance
More data reduces variance
A high-variance model's predictions become more stable as the training set grows — there's less room to memorise noise when there's a lot of data. The train/validation gap shrinks.
More data does NOT fix bias
If your model is fundamentally wrong (linear model on quadratic data), giving it 10× more data won't help. The model architecture or feature set needs to change. Adding data to a biased model wastes compute and time.
Diagnostic rule: plot learning curves (train/val error vs dataset size). If both curves plateau high → high bias. If there's a large gap between them → high variance.
Where specific models sit on the spectrum
High bias ←————————————————————————→ High variance | | Linear regression Unpruned decision tree Naive Bayes k-NN (k=1) Logistic regression Deep neural net (unregularised) Regularisation moves a model LEFT (more bias, less variance): Ridge (L2), Lasso (L1), dropout, weight decay, early stopping
Interview Q & A
Q: Explain the bias-variance tradeoff and how you would diagnose which problem a model has.
A: Prediction error = Bias² + Variance + Irreducible noise. Bias is error from wrong assumptions — the model is systematically wrong regardless of data. Variance is error from sensitivity to training data — the model memorises noise. To diagnose: compare training error and validation error. If both are high → high bias (underfitting) — try a more complex model, add features, reduce regularisation. If training error is low but validation is much higher → high variance (overfitting) — try regularisation (L1/L2), dropout, early stopping, or more data. Learning curves (error vs dataset size) are the cleanest diagnostic: plateau high = bias problem; large gap = variance problem.
4.3
Hypothesis testing & p-values
Deciding whether an observed pattern is real or just noise
High priority

Every time you deploy a new model and ask "is this better than the old one?", you are running a hypothesis test. A/B testing — the standard way to evaluate model changes in production — is applied hypothesis testing. Data science roles test this heavily because it separates engineers who make decisions based on evidence from those who make decisions based on vibes.

You'll be asked about p-values, Type I/II errors, and confidence intervals. The classic trap: "our p-value is 0.03, so our new model is significantly better" — which ignores practical significance, multiple comparisons, and power.

Hypothesis testing starts from scepticism. You assume the boring explanation is true — "there's no effect, any difference I see is just random chance" (null hypothesis). Then you measure how surprising your data would be if that boring explanation were true. If the data is extremely surprising under the null, you reject it.

The p-value answers: "if the null were actually true, how often would I see a result at least this extreme just by luck?" Small p → "this would be very unlikely by luck" → evidence against the null. It does NOT tell you the probability that the null is true.

The framework
Step 1: State hypotheses H₀ (null): "no effect" — e.g. new model accuracy = old model accuracy H₁ (alternative): "there is an effect" — e.g. new model accuracy > old Step 2: Choose significance level α (usually 0.05) This is the false positive rate you're willing to accept. Step 3: Collect data and compute test statistic Summarises how far your observation is from what H₀ predicts. Step 4: Compute p-value p = P(seeing a result this extreme | H₀ is true) Step 5: Decision p < α → reject H₀ (result is statistically significant) p ≥ α → fail to reject H₀ (insufficient evidence)
Type I and Type II errors
H₀ is TRUE H₀ is FALSE ───────────────────────────────────── Reject H₀ │ Type I error ✗ │ Correct ✓ │ │ (False Positive)│ (True Positive) │ │ Rate = α │ Rate = Power (1-β)│ ───────────────────────────────────────────────── Fail to │ Correct ✓ │ Type II error ✗ │ reject H₀ │ (True Negative) │ (False Negative) │ │ Rate = 1-α │ Rate = β │
  • Type I (α): you say "the new model is better" when it isn't. Setting α=0.05 means you accept a 5% false positive rate.
  • Type II (β): you say "no significant difference" when the new model actually is better. Power = 1-β = probability of correctly detecting a real effect.
  • Lowering α reduces Type I errors but increases Type II errors (harder to detect real effects) — the classic tradeoff.
Confidence intervals
A 95% confidence interval means: If we repeated the experiment 100 times, ~95 of the intervals would contain the true parameter value. For a mean: CI = x̄ ± z_{α/2} · (σ / √n) where z_{0.025} = 1.96 for 95% CI Common misinterpretation (WRONG): "There is a 95% probability the true value is in this interval." (The true value is fixed — it either is or isn't in the interval.)

Confidence intervals are more informative than p-values alone — they tell you both statistical significance AND the magnitude and precision of the effect.

Statistical vs practical significance — the critical distinction
Key insight: with a large enough dataset, any tiny difference becomes statistically significant — but may be completely meaningless in practice.
Example: Old model: accuracy = 87.00% New model: accuracy = 87.01% n = 10,000,000 samples → p-value = 0.001 Statistically significant? YES (p < 0.05) Practically significant? Almost certainly NO (0.01% is noise) Always ask alongside p-value: What is the effect size? (Cohen's d, relative improvement %) Does this difference matter for the business/product?
Multiple comparisons problem

If you run 20 hypothesis tests at α=0.05 and nothing is actually different, you'd expect 1 false positive just by chance (0.05 × 20 = 1). This is the multiple comparisons problem — running many tests inflates your effective false positive rate.

  • Bonferroni correction: divide α by the number of tests. If running 20 tests, use α = 0.05/20 = 0.0025 per test. Conservative but simple.
  • FDR (False Discovery Rate): Benjamini-Hochberg procedure controls the expected fraction of false positives among all rejections. Less conservative than Bonferroni.
  • Relevant in ML: testing many features for significance, hyperparameter search, comparing multiple models simultaneously.
Interview Q & A
Q: You ran an A/B test. The p-value is 0.03. Should you ship the new model?
A: Not necessarily — p=0.03 tells you the result is statistically significant at α=0.05, meaning if there were no real difference, you'd see this result only 3% of the time by chance. But I'd ask several more questions before shipping. First, what's the effect size? Is the improvement 0.01% or 5%? Statistical significance doesn't guarantee practical significance, especially with large datasets. Second, did we correct for multiple comparisons if we tested many metrics? Third, was the experiment properly randomised and were the groups balanced? Fourth, how long did we run the test — did we stop early after seeing a positive result (peeking problem)? Only after these checks would I recommend shipping.
4.4
Correlation vs causation
Measuring relationships — and knowing what they actually mean
Good to have

Confusing correlation with causation is one of the most common and costly errors in applied data science. Models trained on correlations will fail the moment the correlation breaks — and it always eventually breaks. Understanding this distinction is the difference between a data scientist who builds robust systems and one who keeps being surprised when models degrade in production.

It also comes up in feature selection (correlated features vs features that actually drive the target), model interpretation (a feature having a high coefficient doesn't mean it causes the outcome), and business recommendations ("our model says X correlates with churn — should we change X?").

Two variables can move together for three reasons: X causes Y, Y causes X, or a third variable Z causes both X and Y. Correlation only tells you they move together — it says nothing about why. Causation requires ruling out the other two explanations, which requires either a randomised experiment or careful causal reasoning.

The ice cream and drowning example: both rise in summer, not because ice cream causes drowning, but because hot weather (a confounder) causes both. Your model will learn this correlation happily — and then give you the wrong recommendation ("ban ice cream to prevent drowning").

Pearson correlation coefficient
r = Cov(X, Y) / (σₓ · σᵧ) = Σ(xᵢ - x̄)(yᵢ - ȳ) / √[Σ(xᵢ-x̄)² · Σ(yᵢ-ȳ)²] Range: -1 to +1 r = +1 → perfect positive linear relationship r = 0 → no linear relationship (may still be non-linear) r = -1 → perfect negative linear relationship

Pearson r measures only linear relationships. Two variables can have r=0 and still have a strong non-linear relationship (e.g. Y = X²). This is a critical limitation.

Also, r is scale-invariant — multiplying X or Y by a constant doesn't change r. But unlike covariance, r is unitless and directly comparable across different pairs of variables.

Spearman rank correlation
Spearman ρ = Pearson r applied to the RANKS of X and Y (instead of the raw values) When to use Spearman instead of Pearson: → Relationship is monotonic but not linear (e.g. diminishing returns) → Data has outliers (ranks are robust; raw values are not) → Data is ordinal (ratings, rankings)

Spearman asks: "when X goes up, does Y tend to go up?" (monotonic), whereas Pearson asks: "when X goes up by 1 unit, does Y go up by exactly r units?" (linear). Spearman is more robust and often more appropriate for ML feature analysis.

Confounders — the hidden cause
Confounder Z causes both X and Y, creating a spurious correlation: Z (hot weather) ↙ ↘ X (ice cream) Y (drowning) X and Y are correlated, but X does NOT cause Y. Controlling for Z removes the correlation. In ML: Feature X correlates with target Y in training data → but only because both depend on confounder Z → in production, Z changes → correlation disappears → model degrades unexpectedly
Common example in ML: "users who open the app on Tuesdays churn less." Confounder: power users happen to use the app more and happen to churn less — Tuesday usage correlates with being a power user, not with churn causally. Sending notifications on Tuesdays won't reduce churn.
Establishing causation
Randomised controlled trial (RCT)
Randomly assign subjects to treatment/control. Random assignment breaks the link between confounders and treatment — any difference in outcome must be caused by the treatment. Gold standard for causation. Often not feasible (ethical, cost, or impossible to randomise).
Causal inference (observational data)
When RCT isn't possible: use propensity score matching, instrumental variables (IV), difference-in-differences, or regression discontinuity. These try to approximate random assignment from observational data. More assumptions, less clean — but often the only option in production ML.

For most ML interviews, the key is to demonstrate awareness: correlation ≠ causation, confounders exist, and acting on a correlational finding without causal reasoning can waste resources or cause harm.

Interview Q & A
Q: Your model finds that a feature X is highly correlated with the target Y. Can you conclude that X causes Y? How would you investigate?
A: No — correlation only tells us X and Y move together, not why. There are three possible explanations: X causes Y, Y causes X (reverse causation), or a confounder Z causes both. To investigate: first, does the causal direction make sense from domain knowledge? Second, check for potential confounders — variables that might drive both X and Y — and try controlling for them (partial correlation or regression with confounders as covariates). Third, if feasible, run a randomised experiment: randomly vary X and see if Y changes. If an RCT isn't possible, causal inference techniques like instrumental variables or diff-in-diff can help. In production ML, it's especially important because a spurious correlation will break when the underlying joint distribution shifts, causing model degradation.