ML Interview Question Patterns

ML interviews recycle a small set of question families. Learn the families and each new prompt becomes a variant instead of a surprise. The three you meet in almost every loop: a derivation you perform live, a diagnostic you explain, and an interpretation you defend.

For the derivation, the failure mode is starting to scribble. State the loss before you differentiate it — the derivation is graded on structure, not speed. Work it as: define notation, write the objective, differentiate term by term, simplify, state the update.

With ŷ = wᵀx and mean squared error:

L(w) = (1/N) Σ (y_i - w_iᵀx_i)²
∂L/∂w = (1/N) Σ 2(y_i - wᵀx_i) · (-(x_i))   # chain rule on the residual
      = -(2/N) Σ x_i (y_i - wᵀx_i)           # the classic normal-equations form
update:  w ← w - η · ∇L(w) = w + (2η/N) Σ x_i (y_i - wᵀx_i)

Say aloud the three variants afterward — stochastic (one sample), mini-batch (the practical default), and the learning rate's role in trading convergence against stability — because that is where the follow-up questions live. If they ask for code, ten lines is enough:

def gradient_step(X, y, w, eta):
    grad = -(2 / len(y)) * X.T @ (y - X @ w)   # one line, same math as the board
    return w - eta * grad

Two follow-ups are near-guaranteed, so pre-load them. "What if the loss oscillates instead of converging?" — the step is too large for the local curvature: lower the learning rate or add momentum, and note that mini-batch noise acts like a regularization term that fades as the batch grows. "Why does feature scaling matter here?" — because each coordinate's gradient magnitude is proportional to that feature's units, so unscaled inputs give effectively different step sizes per coordinate; the error contours stretch into narrow ravines and a naive step bounces across them instead of descending. Both answers are corollaries of the gradient you just derived, which is exactly why the derivation is worth performing slowly rather than recalling as a memorized formula.

The diagnostic family keys off the decomposition E[(y - ŷ)²] = bias² + variance + noise. Map symptoms to terms instead of reciting definitions:

Interviewers notice candidates who claim "low train error means the model is great" without naming variance; the follow-up is almost always "so what would you change first?" — answer with the lever, and reference the systematic treatment in Diagnosing the Generalization Gap.

The interpretation family — "which features matter?" — is won by separating three things: importance is method-dependent, correlation splits credit, and importance is not causation. A defensible answer: "I'd compute permutation importance on the time-based holdout — shuffle the column, measure the metric drop — then check direction with partial dependence and confirm the ranking is stable across folds. Coefficients only rank features if inputs were standardized first; SHAP gives per-prediction attributions when I need to explain an individual case." Name the caveat before they do; that is the whole point of the question.

"Fraud is 0.3% of transactions. What metric do you optimize?" This is the metric-choice family, and it is asked as often as derivations because the wrong answer reveals someone who optimizes numbers instead of decisions.

Start by doing the arithmetic out loud. One million transactions a day, 3,000 genuinely fraudulent. Your model flags the top 4,000 for review and catches 2,400 of them:

Precision = 2,400 / 4,000 = 60%. Recall = 2,400 / 3,000 = 80%. Accuracy = 99.78% — while the "flag nothing" classifier scores 99.70%. With a 0.3% base rate, accuracy measures nothing; precision at your review capacity is the number that pays, and the 0.08-point accuracy gap between a useless model and a strong one is exactly why interviewers use this example.

Build the metric answer from the constraint, not from habit:

Why not ROC-AUC, the default answer many candidates give? It plots true against false positive rate across every threshold, and with 99.7% negatives the false-positive denominator is enormous — a model can look superb on that curve while still burying the review team in false alarms. Precision-recall trades in the numbers operations actually feels: of the flags, how many were real; of the fraud, how much got through. Saying that asymmetry out loud — "ROC-AUC hides false-positive cost under imbalance" — is the sentence this question is fishing for.

Then connect metric to threshold, which is where the strongest candidates separate themselves. Flag a transaction when the expected cost of clearing exceeds the cost of reviewing: with a $15 review and a $500 average loss, predict fraud whenever p > C_FP / (C_FP + C_FN) = 15 / 515 ≈ 0.029. That single line requires calibrated probabilities — which loops back to log-loss — and it shows you treat the metric as a decision rule with a cost model behind it, not a scoreboard.

Interviewers also probe the imbalance toolkit, so have the order ready: move the threshold first (no retraining, no new risk), then class weights or focal loss if the model never learns the minority class, then resampling — with two warnings attached. Oversampling the minority duplicates examples and distorts the probabilities you ship, so recalibrate afterward (isotonic or Platt scaling on a clean validation fold) before any cost-based threshold trusts them. And rebalance only the training fold: resample the test set as well and your precision describes a prevalence the production system will never see. Reach for anomaly detection only when labels are genuinely scarce, not because the classes are unequal. Close by restating the pipeline: base rate → constraint → metric → threshold → the trade-off you are deliberately accepting.

Two families remain, and both are about judgment rather than math: catching leakage, and narrating your own failure. Interviewers probe failures to watch how you localize cause — not to hear that you worked hard.

Leakage questions usually arrive disguised as a success story: "My model got 0.98 AUC — oh, and one feature is days_to_default, computed from the customer's payment history." Learn the four flavors and their signatures:

The detection heuristic to say in the room: when a feature's importance is implausibly high or a score implausibly good, audit its construction timeline before celebrating. A quick ablation — drop the suspect column, retrain — converts suspicion into evidence in one run.

The reproducibility question ("how would someone else reproduce your numbers?") is a four-part answer: freeze and hash the dataset, pin dependencies in a lockfile, fix seeds and record the config with the git SHA, and report a tolerance — a mean over three seeds rather than one figure. That answer is deliberately identical to what a portfolio must demonstrate; Portfolio and Reproducibility turns it into artifacts a reviewer can execute. Two follow-ups are worth having ready: "what if someone cannot get your data?" — publish the fetch script with license notes, and where redistribution is barred, ship a synthetic generator plus the checksum of the original so their pipeline still runs end to end; "how do you know the numbers hold next quarter?" — you do not, so you re-run evaluation on a refreshed snapshot on a schedule and treat any move outside the declared tolerance as a bug report against either the data or the model, whichever the drift monitor implicates.

The failure narrative is the question candidates rehearse least, and it costs them the most. Structure it in three minutes with fixed beats:

1. Context — two sentences: what the model decided, and the baseline it had to beat.
2. The claim — what you shipped and the metric that looked good (0.93 AUC).
3. The crack — who noticed, and what measurement exposed it (a retrain on fresh data scored 0.78).
4. Root cause — one specific mechanism (a feature joined against post-outcome data).
5. The fix and the delta — recomputed as-of, retrained, landed at 0.81, still +0.09 over baseline, shipped with a drift alarm on the repaired feature.

The tempting version — "it was hard, I tried many things, eventually it worked" — answers nothing. The scored version names the instrument that revealed the failure, the mechanism, and what you changed in your process afterward: now every feature gets a construction-timeline review before it enters training. Practice it aloud against a stopwatch once: three minutes is roughly 450 spoken words, which enforces the discipline of one cause and one fix instead of a tour of every experiment you ran. If the interviewer interrupts to ask what the metric was, you are in the part of the answer they care about — keep the numbers ready and the chronology intact. That last beat is the one they remember, because it shows the failure produced a system, not just a lesson.