12 Machine Learning Interview Questions to Ask Before You Hire

A strong answer describes a specific project with a named business problem, explains the candidate's reasoning for the model family chosen with reference to at least two of the following: data volume, inference latency requirement, interpretability need, deployment target, and accuracy threshold. It describes at least one alternative that was considered and rejected with a reason. It mentions how the choice was validated. For example: the team needed a fraud classifier that could run inference in under 50 milliseconds on CPU for a payment API, so LightGBM was chosen over a deep learning approach because gradient boosted trees reach comparable accuracy on structured financial data at a fraction of the inference cost, and the model was validated against a held-out test set stratified by fraud rate before deployment.

A weak answer names the model without business context: 'I used XGBoost because it usually performs well on tabular data.' It describes no alternative considered and no validation performed. It treats model selection as a default rather than a decision. This pattern indicates the candidate followed a tutorial template rather than designed a solution to a specific problem.

A strong answer describes specific data quality problems encountered in a named project and the specific decisions made to address them. It distinguishes between imputation strategies and explains why random imputation was or was not appropriate for the specific missing data mechanism. It describes how label quality was validated, whether through inter-annotator agreement measurement, comparison to a gold standard, or random auditing by a domain expert. It mentions the tools used: pandas profiling for initial audit, Great Expectations or Pydantic for schema validation in the pipeline, and dbt or custom SQL for transformation lineage. Shreyans Padmani's ML development practice, documented across production systems on 

shreyans.tech, involves data pipelines built to specific client data structures with validation steps designed before model training begins, not added as a patch when training failures expose data problems.

A weak answer says the candidate cleaned the data without describing what cleaning meant, which problems were found, or how the cleaning decisions were validated. It treats data preparation as a step that is completed once rather than a continuous pipeline component that requires monitoring as new data arrives.

A strong answer names the specific metric, explains why it was chosen over alternatives with reference to the business cost of different error types, and describes the threshold at which the metric was considered acceptable. For a medical symptom classifier: precision-recall tradeoff was the governing consideration because a false negative (missed positive case) had a higher cost than a false positive (unnecessary follow-up), so recall was maximised at a threshold where precision remained above 85 percent. For a recommendation engine: NDCG@10 was used because the business value is concentrated in the top ten recommendations displayed to users, and lower-ranked recommendations have negligible commercial impact. The metric choice should be traceable to a business decision, not a default.

A weak answer reports accuracy without acknowledging the class distribution of the problem, or names F1 score as the default without explaining why F1 was preferred over precision, recall, or AUC-ROC for the specific use case. It treats metric selection as a technical convention rather than a business-grounded decision.

A strong answer describes a specific monitoring approach in production: tracking input feature distribution statistics (mean, variance, and percentiles for numerical features; class frequency for categorical features) against the training baseline, with defined alert thresholds that trigger investigation when drift exceeds a specified level. It names the tools used: Evidently AI for data drift detection, MLflow for model performance tracking, or custom dashboards comparing prediction confidence distributions against the baseline. It describes the retraining trigger: whether retraining is scheduled on a calendar cadence, triggered by drift metrics exceeding a threshold, or triggered by a decline in a downstream business metric. Shreyans Padmani's ML systems, documented across 12 case studies at AI case studies, each include monitoring and optimisation as a defined post-deployment phase rather than an optional addition.

A weak answer describes model drift conceptually without describing any monitoring system in place. It conflates model drift with model accuracy without explaining how accuracy is measured in production when ground truth labels arrive with a delay. It treats monitoring as something the operations team handles rather than something the ML developer designs into the system before deployment.

A strong answer describes specific feature engineering decisions in a named business domain and explains the reasoning behind each in terms of the business process being modelled. For an e-commerce demand forecasting model: a rolling 7-day sales velocity feature was engineered to capture short-term trend rather than using raw daily sales, because raw daily sales were noisy due to promotional events; a days-since-last-purchase recency feature was added based on the hypothesis that purchase likelihood decays with recency, which was validated by measuring the feature's correlation with the target before including it. The candidate describes features that were tested and removed because they did not improve validation performance, which demonstrates that feature selection was disciplined rather than additive.

A weak answer lists standard transformations without domain context: normalisation, one-hot encoding, log transformation of skewed features. These are preprocessing steps, not feature engineering. A candidate who cannot describe a feature they created specifically for the business problem being solved has not done domain-grounded feature engineering on a real ML project.

A strong answer describes a held-out test set that is representative of the production data distribution and is not used during model development or hyperparameter tuning. It describes the evaluation script that runs against the test set, the metric thresholds that must be met for a model to pass, and the process by which a model that fails the evaluation is diagnosed. It describes how the evaluation is triggered: manually before each deployment, automatically in a CI/CD pipeline on each model training run, or both. It mentions what happens when a model fails: whether the previous model version is retained, an alert is sent, and an investigation is opened. A developer who describes this process has built and maintained production ML systems.

A weak answer describes evaluating the model in a Jupyter notebook by looking at a confusion matrix and some sample predictions. This is exploratory evaluation, not a deployment gate. The absence of a held-out test set not used during training, a minimum metric threshold, and an automated evaluation script indicates that model quality has been assessed subjectively rather than measured systematically.

A strong answer describes the specific imbalance ratio in a named project, the strategy chosen to address it, and how the choice was validated. It distinguishes between approaches: class weighting in the loss function (computationally free, often effective for mild imbalance), oversampling with SMOTE or similar (useful for moderate imbalance, but can introduce synthetic artefacts), undersampling the majority class (appropriate when majority class has redundant examples), and collecting more minority class data (the correct answer when budget and time allow). It describes why the chosen approach was selected over the alternatives for the specific project. It describes how the model's performance on the minority class was measured separately from overall performance, using per-class precision and recall rather than macro metrics that can obscure minority class performance.

A weak answer says the candidate used SMOTE without describing the imbalance ratio, why SMOTE was chosen over class weighting, or whether performance on the minority class improved as a result. It treats class imbalance handling as a technique to apply rather than a decision to make based on the specific problem characteristics.

A strong answer describes input validation at the inference endpoint that checks incoming features against the training distribution before the model processes them. It describes the behaviour when an out-of-distribution input is detected: whether it is flagged for human review, sent to a fallback rule-based system, or processed with a confidence score that is surfaced to the downstream application so it can decide whether to use the prediction. It describes the pipeline for logging out-of-distribution inputs so they can be used to update the training data and retrain the model. A developer who has designed this system has thought about ML engineering as a continuous loop between deployment and training, not a one-way pipeline from training to deployment.

A weak answer describes what model drift is without describing any system behaviour when it occurs. It treats distribution shift as something the developer monitors and responds to, rather than something the system detects and handles automatically. For production ML systems serving high request volumes, human-in-the-loop detection of distribution shift is too slow to prevent degraded user experience.

A strong answer describes the decision framework applied in a specific project: when the training dataset was small (fewer than 10,000 labelled examples) and the target domain was similar to the pre-training domain (ImageNet for natural images, general web text for English NLP), fine-tuning was chosen because the pre-trained features transferred effectively and training from scratch would have required more data than was available. When the target domain was significantly different from any available pre-trained model (specialised industrial sensor data, domain-specific legal language with unusual vocabulary), the developer assessed whether fine-tuning a general model would reach adequate performance or whether the domain gap was large enough to justify training a domain-specific model from scratch. The answer should include at least one example where fine-tuning was not the right choice.

A weak answer says the candidate always fine-tunes because it is faster and requires less data, without being able to describe when fine-tuning produces worse results than training from scratch or training a simpler model designed for the specific data characteristics. It treats fine-tuning as universally superior rather than as one option in a set.

A strong answer describes a specific deployment architecture with named components: the model was serialised to ONNX format for framework independence, wrapped in a FastAPI inference endpoint with Pydantic input validation, containerised with Docker, deployed to AWS Lambda for a low-traffic endpoint or an EC2 GPU instance for a high-throughput transformer model, with CloudWatch monitoring for request latency and error rate, and a Redis cache for repeated identical inputs. It describes how model updates were deployed: a new container image was built, the evaluation suite was run against the held-out test set, and the new image replaced the old one with a zero-downtime rolling update. Shreyans Padmani's machine learning development services include deployment as a first-class deliverable in every engagement, with each case study documenting a production system rather than a trained model in a notebook.

A weak answer describes saving a pickle file and loading it in a Flask app that runs on a local machine. It does not mention containerisation, a cloud deployment target, monitoring, or a model update strategy. This description is of a prototype environment, not a production deployment. A developer who has shipped a production ML system will describe an infrastructure that handles traffic from external users, not a notebook server that handles requests from the developer's own laptop.

A strong answer describes specific interpretability methods used in a named project with a specific stakeholder audience in mind. For a tabular model: SHAP values were used to explain individual predictions, with a summary plot showing which features drove the model's output for a specific customer churn prediction, presented to the business team as 'this customer is at high churn risk primarily because their last purchase was 87 days ago and their support ticket volume doubled last month.' For a computer vision model: Grad-CAM was used to generate heatmaps showing which image regions activated the model's classification, presented to quality inspectors as visual overlays on the defect detection output so they could validate that the model was looking at the right part of the image. The answer should connect the interpretability method to the specific trust or compliance need it was addressing.

A weak answer says the candidate explains the model's accuracy to stakeholders or describes the model architecture in simplified terms. Accuracy is a property of the model in aggregate, not an explanation of a specific prediction. A stakeholder asking why the model predicted this customer would churn is not served by a statement that the model is 87 percent accurate. The weak answer reveals that the developer has not been asked to explain individual predictions to stakeholders with business accountability for the decisions the model influences.

A strong answer identifies a specific decision that the candidate would change in retrospect, explains the consequence of the decision made, and describes what they would do differently. For example: the training and validation sets were split randomly rather than by time period, which caused the model to perform better in validation than in production because future data leaked into the training set through the random split. In retrospect, a time-based split would have produced a more realistic validation performance estimate, and the model would have been tuned differently. This answer demonstrates that the candidate understood what went wrong, why it went wrong, and how to prevent it in the next project. It also reveals that they have thought carefully about their work beyond delivering the requested output.

A weak answer says the candidate would have liked more time, more data, or more compute. These are resource constraints, not engineering decisions. A developer who can only identify resource constraints as the limiting factor on their past work has not reflected on the engineering decisions that were within their control and could have been made differently. The absence of a specific technical decision the candidate would change is a signal that either the project was a tutorial exercise without consequential decisions, or the candidate is performing competence in the interview rather than describing it from experience.