Machine Learning Engineer
Interview Questions.

What the interviewer is looking for: Strong answers emphasise productionising, serving, scaling, and reliability of models versus pure experimentation. Treating the roles as identical or ignoring the engineering half is a red flag.

What the interviewer is looking for: Look for regularisation, more/better data, cross-validation, early stopping, and simpler models, with an understanding of the bias-variance trade-off. Only saying 'add more layers' is a red flag.

What the interviewer is looking for: A strong answer explains information from the target or future leaking into features, e.g. using a post-outcome field, and how to catch it. Not recognising leakage as a top failure mode is a serious red flag.

What the interviewer is looking for: Strong candidates name data/concept drift, set up monitoring, and plan retraining triggers. Only suggesting a one-off retrain without monitoring is a red flag.

What the interviewer is looking for: Strong candidates check offline metrics against a baseline, latency and cost budgets, and a shadow or canary rollout, not just a good validation score. Shipping on a single accuracy number is a red flag.

What the interviewer is looking for: Look for containerisation, a serving layer or API, autoscaling, and monitoring of latency and errors. Loading the model per request or ignoring latency budgets are red flags.

What the interviewer is looking for: Look for handling missing values, scaling, encoding, and especially preventing train/serve skew and data leakage. Not mentioning leakage or reproducibility of transforms is a red flag.

What the interviewer is looking for: Look for a pragmatic view — research flexibility and dynamic graphs versus production/serving ecosystems — rather than dogma. Insisting one is universally better is a red flag.

What the interviewer is looking for: Strong answers cover seeding, pinned dependencies, config-driven runs, and versioned data and artifacts. Notebooks with hidden state as the production pipeline are a red flag.

What the interviewer is looking for: Look for data and model versioning, retraining pipelines, drift monitoring, and reproducibility, not just CI/CD. Treating a model like a static binary that never degrades is a red flag.

What the interviewer is looking for: Strong answers pin the environment including CUDA/library versions and use the same base for train and serve. 'Works on my machine' with unpinned dependencies is a red flag.

What the interviewer is looking for: Look for starting simple with prompting/RAG for knowledge grounding and reserving fine-tuning for behaviour/format needs, weighing cost and data. Jumping to fine-tuning by default is a red flag.

What the interviewer is looking for: Strong candidates combine automated proxies, human evaluation, and guardrails for safety and hallucination, and define task-specific criteria. Claiming accuracy alone suffices is a red flag.

What the interviewer is looking for: Strong answers check the learning rate, data pipeline and labels, loss function choice, and whether the model can overfit a tiny batch as a sanity test. Randomly tweaking hyperparameters with no hypothesis is a red flag.

What the interviewer is looking for: Look for versioning code in Git, data and large artifacts via a data-versioning tool or object storage with references, and pinned environments. Committing giant binaries to Git or not versioning data at all are red flags.

What the interviewer is looking for: Strong answers document data sources, assumptions, metrics, and how to run the pipeline, valuing reproducibility. Undocumented notebooks and tribal knowledge are red flags.

What the interviewer is looking for: Look for understanding that model quality is only part of impact — integration, UX, and the right metric matter. Blaming only the model or the data is a red flag.