Machine Learning Interview Guide

Machine learning interviews have a grading curve most candidates never see: everyone can name algorithms, so naming them earns nothing. The points live in diagnosis — your model underperforms, and the interviewer wants to watch you figure out why. Bias or variance? Leakage or noise? Bad metric or bad data? That diagnostic instinct is learnable, and it's exactly what this guide drills.

The core idea: Modelling is a loop of forming hypotheses about error and testing them. Interviewers simulate that loop with scenario questions — and grade whether your hypotheses are ordered by likelihood, not by textbook chapter.

The diagnostic core: bias and variance

Everything starts here. High bias (underfitting): the model is too simple to capture the pattern — training error is high. High variance (overfitting): the model memorised the training set — training error is low, validation error is high. Memorise the remedies as pairs: underfitting gets a more expressive model, more features, less regularisation; overfitting gets more data, simpler model, more regularisation, better validation. When a scenario question lands, your first move is always: what do the training and validation errors look like?

Worked example: "my model does great offline and terribly in production"

The single most diagnostic ML question. Work the hypotheses in order of likelihood:

1. Leakage. A feature that wouldn't exist at prediction time snuck into training — the classic. The model learned the answer key, not the problem.
2. Distribution shift. Training data doesn't match production — different time period, different population, different logging.
3. Training/serving skew. Features computed differently in the pipeline than in training — normalisation fitted on the full dataset, a bug in the serving transform.
4. Feedback loops. The model's own predictions changed the world it's now predicting.

Notice the ordering: leakage first because it's the most common and the most embarrassing. That prioritisation — most likely, most damaging — is what a senior answer sounds like.

Metrics: choose like the business depends on it

Because it does. Accuracy on imbalanced data is a lie; precision and recall trade off against each other, and the right point on that curve is a business decision — what's the cost of a false positive versus a false negative? In ranking problems, know why AUC can hide calibration problems. And always be able to answer: "what metric would you report to a product manager, and what would you watch as an engineer?" They're often different, and saying so is a mark of maturity. The data scientist guide drills the business framing further.

Common mistakes

• Tuning on the test set. It silently becomes training data and your estimates turn optimistic.
• Random train/test splits on time-series data — you're training on the future. Split by time.
• Scaling features before splitting, leaking test-set statistics into training.
• Answering scenario questions with algorithm names instead of a diagnostic process.

Feature engineering and data questions

Don't let model talk crowd out the data — interviewers at strong teams spend real time here. Expect "how would you handle missing values?" (it depends on the mechanism: missing at random versus missing informatively are different problems, and a missingness indicator is sometimes the feature), "how do you encode high-cardinality categoricals?" (one-hot explodes; consider target encoding with cross-validation discipline to avoid leakage, or embeddings), and "how do you know a feature is worth keeping?" (importance measures, ablation, and the honesty to admit that a feature that helps offline may be too stale or too expensive in production). The thread connecting good answers: every transformation is a hypothesis about the data, and every hypothesis needs validation. Candidates who treat feature engineering as a checklist get through the question; candidates who treat it as an experiment get the offer.

FAQ

Do I need to derive the math — gradients, proofs? For research and some ML-heavy roles, yes. For most engineering roles, conceptual mastery with correct intuition beats shaky derivations.

How much coding is involved? Expect a real coding round plus ML-flavoured implementation — writing a clean training loop or a metric from scratch. See the AI/ML engineer guide for the production side.

Practise scenario diagnosis out loud with Aissence practice, and keep your Python sharp with the coding copilot.