Machine Learning Engineer Interview Questions
ML engineering interviews are not a Kaggle contest. They test whether you can spot the silent bugs that make a model look great offline and fail in production: a feature that leaks the label, a preprocessing step fitted before the split, a serving endpoint whose schema drifted from its clients, a metric computed the wrong way. Gronex lets you practice those exact failures in real Python repositories with failing tests — scikit-learn, FastAPI, and numpy, all CPU-only — so you rehearse the round, not a modelling competition.
What ML engineering interviews test
The hard part of an ML role is rarely the model — it is the engineering around it. Interviewers want to know whether you would catch a data leak before it inflated your validation score, whether your serving contract stays honest as clients depend on it, whether your metrics mean what you think they mean, and whether your training loop is reproducible and actually converging. These are the failures that do not raise an exception; they just quietly make the wrong thing look right.
Every challenge here is a real Python repository with a bundled verify step (pytest). The tests are deliberately structural and bounded — they assert that a transform was fitted on the training indices only, that a leaky column is gone, that a metric lands in a correct band, or that loss strictly decreases — never an exact score that would flake across library versions. Everything runs on CPU in seconds; no GPU, no cluster.
Common patterns in ML engineering rounds
Train/test discipline
Fitting every transform on the training fold only, so no information from the test set — or the label — leaks into features.
Serving contracts
A prediction API whose request and response schema, validation, and error handling match what clients actually call.
Metric correctness
Computing precision, recall, and pooled averages the way the evaluation harness expects — no per-batch shortcut that skews the number.
Reproducible training
Fixed seeds and a correct gradient so the same run produces the same model and the loss actually goes down.
Debugging silent ML bugs
The failures that do not throw — a leaky feature, a swapped metric, a wrong-sign gradient — caught by structural, bounded tests.
Reading unfamiliar ML code
Navigating a pipeline, a trainer, or a serving app quickly and fixing the defect without a rewrite.
Problems to practice
Each is a real Python repository with a failing test suite. Open the brief and fix it — no signup required to read the full problem.
Data Leakage in a Feature Pipeline
Move the scaler/encoder fit inside the train fold and drop a target-derived feature that leaks the label.
Open the challenge →Model Serving Prediction API Contract
Fix the Pydantic request/response schema and input validation on a FastAPI /predict service.
Open the challenge →Metric Computation & Pooling
A precision/recall miscompute and per-batch averaging that disagrees with pooled ground truth.
Open the challenge →Training Loop Gradient Bug
A from-scratch logistic-regression trainer whose regularization gradient has the wrong sign, so loss diverges.
Open the challenge →Guided walkthroughs
Data Leakage in a Feature Pipeline
A preprocessing pipeline that fits on the whole dataset before the split — the leak that inflates every offline metric.
Read the walkthrough →Model Serving Prediction API Contract
A FastAPI /predict endpoint whose schema and validation do not match the contract clients depend on.
Read the walkthrough →