Machine Learning Engineer Interview Questions

The bias-variance tradeoff is fundamental to ML model performance. Bias refers to underfitting - when a model is too simple to capture underlying patterns, leading to systematic errors. High bias models perform poorly on both training and validation data. Variance refers to overfitting - when a model is too complex and sensitive to training data noise, performing well on training but poorly on new data. To diagnose: high bias shows poor performance on both train/validation sets with similar error rates, while high variance shows low training error but high validation error. For high bias, I'd increase model complexity, add features, or reduce regularization. For high variance, I'd apply regularization (L1/L2), use cross-validation, collect more data, or reduce model complexity. In production, I monitor both training and validation metrics continuously and use techniques like ensemble methods to balance this tradeoff.

I'd design a two-stage ranking system. Stage 1: Candidate retrieval using BM25 for text matching plus approximate nearest neighbor search on product embeddings, returning top 500-1000 products for low latency. Stage 2: Neural ranking model with features including product attributes (price, ratings, reviews), user features (purchase history, demographics), contextual features (query, time, location), and interaction features (click-through rates, conversion rates). I'd use a neural network with embedding layers for categorical features and dense layers, optimized for ranking loss like ListNet or RankNet. For evaluation, offline metrics include NDCG@10, MAP, and MRR on historical data. Online A/B testing measures business metrics like click-through rate, conversion rate, and revenue per search. The system needs real-time inference under 100ms, so I'd use model serving infrastructure with caching popular queries and pre-computed embeddings. I'd also implement monitoring for model drift and fairness across different product categories.

I use several techniques depending on the situation. Regularization: L1/L2 regularization penalizes large weights, with L1 promoting sparsity and L2 preventing any single weight from becoming too large. Dropout randomly sets neurons to zero during training, forcing the network to not rely on specific neurons. Early stopping monitors validation loss and stops training when it starts increasing. Data augmentation artificially increases training data through transformations like rotation, scaling, or noise injection - especially effective for computer vision. Cross-validation helps detect overfitting and select hyperparameters robustly. Reducing model complexity by decreasing layers or neurons when you have limited data. Batch normalization can act as regularization by adding noise. For choosing techniques: use dropout and batch norm for deep networks, data augmentation for image/text tasks with limited data, L2 regularization when you suspect many irrelevant features, and early stopping as a general safety net. I typically combine multiple techniques and tune their strength based on validation performance.

At my previous company, our recommendation system's CTR dropped 15% overnight after a model deployment. I immediately initiated a systematic debugging process. First, I checked data pipeline health and found our feature extraction was receiving corrupted user behavior logs due to a schema change upstream. The model was getting null values instead of user interaction features. I coordinated with the data engineering team to implement schema validation and backfilled the missing data. However, performance was still suboptimal. Digging deeper, I discovered the training data had shifted - our model was trained on pre-pandemic user behavior, but post-deployment behavior patterns had changed significantly. I proposed and implemented a retraining pipeline with recent data and added monitoring for data drift detection. I also set up alerting for key metrics like CTR, precision, and feature distribution changes. The fix improved CTR by 20% above the original baseline. This experience taught me the importance of comprehensive monitoring and having robust data validation in ML pipelines.

I needed to explain why our fraud detection model had a 2% false positive rate to our product team, who were concerned about blocking legitimate customers. Instead of diving into technical metrics, I started with business impact: 'Out of 10,000 transactions, we correctly identify 98% of legitimate ones, but 2% get flagged for manual review.' I used analogies, comparing it to airport security - some false alarms are inevitable for safety. I created visualizations showing the trade-off between catching fraud and customer experience, demonstrating that reducing false positives to 1% would let 30% more fraudulent transactions through, costing $500K monthly. I presented three options with clear business implications: accept current performance, invest in better features to improve precision, or adjust thresholds based on transaction value. The key was focusing on dollars and customer impact rather than technical metrics like precision/recall. I also set up a dashboard they could understand, showing 'legitimate customers affected' and 'fraud dollars prevented.' This approach helped them make an informed decision to invest in model improvements.

My team wanted to deploy a complex ensemble model that achieved 2% better accuracy than a simpler neural network, but I disagreed due to maintenance and latency concerns. The ensemble required 10x more inference time and involved three different model types that would need separate maintenance. I approached this by preparing a comprehensive analysis showing the trade-offs. I documented that the 2% accuracy gain translated to only $50K additional annual revenue, while the ensemble would require 2 additional engineer-months for maintenance and increase our infrastructure costs by $200K yearly due to higher compute requirements. I presented this data to the team lead privately first, showing respect for their decision while providing evidence. I also proposed a compromise: we could achieve 1.5% of the accuracy gain with a single optimized neural network that had 20% of the complexity. Rather than just criticizing, I offered solutions. The team agreed to try my approach first, and if business metrics showed we needed the extra 0.5% accuracy, we'd revisit the ensemble. This taught me that disagreements are opportunities to find better solutions through data-driven discussions and creative alternatives.

First, I'd check for data drift by comparing production data distributions to training data using statistical tests like KS-test or PSI. I'd examine feature distributions, missing values, and data quality issues. Next, I'd investigate model monitoring metrics to identify which specific predictions are failing. I'd validate the data pipeline for any preprocessing inconsistencies or feature engineering bugs. If data drift is confirmed, I'd retrain the model with recent data or implement online learning. I'd also check for concept drift by analyzing if the relationship between features and target has changed. Throughout this process, I'd implement proper logging and alerting systems to catch similar issues early. Finally, I'd establish a regular retraining schedule and robust monitoring dashboard to prevent future degradation.

With such extreme imbalance (1:1000 ratio), I'd employ a multi-pronged approach. First, I'd use stratified sampling to ensure positive cases are represented in train/validation splits. For resampling, I'd combine SMOTE for oversampling with Tomek links for undersampling to clean decision boundaries. Given the 95% recall requirement, I'd use cost-sensitive learning with class weights inversely proportional to class frequency, or adjust the classification threshold using precision-recall curves. I'd implement ensemble methods like balanced random forests or EasyEnsemble. For evaluation, I'd focus on precision-recall AUC rather than ROC-AUC, and use metrics like F2-score that emphasize recall. I'd also consider anomaly detection approaches like Isolation Forest or One-Class SVM. Finally, I'd validate using time-based splits to ensure the model generalizes to future data patterns.

I'd design a hybrid architecture with multiple recommendation layers. For real-time serving, I'd use a two-stage approach: candidate generation and ranking. For candidate generation, I'd precompute user embeddings using collaborative filtering and content-based features, stored in Redis for sub-millisecond lookup. I'd use approximate nearest neighbor search (like Faiss) to quickly find similar users/items. For ranking, I'd deploy lightweight models like logistic regression or shallow neural networks using TensorFlow Serving or MLflow. The architecture would include: load balancers, microservices for different recommendation types, feature stores (like Feast) for real-time features, and caching layers. I'd implement A/B testing infrastructure and real-time model monitoring. For continuous learning, I'd use online learning algorithms to update user preferences. The system would fallback to popularity-based recommendations if personalized models fail, ensuring reliability.

For time-series feature engineering, I focus on creating temporal patterns that capture trends, seasonality, and cyclical behaviors. I'd generate lag features (previous values), rolling statistics (mean, std, min, max over windows), and difference features to capture changes. I'd create time-based features like day of week, month, holidays, and seasonal indicators. For preventing data leakage, I strictly use time-based splits ensuring no future information leaks into training. I'd be careful with rolling window calculations to only use historical data. When creating features, I'd ensure the 'as-of' time is always before the prediction time. I'd implement proper cross-validation using time-series splits or walk-forward validation. For missing values, I'd use forward-fill or interpolation methods appropriate for temporal data. I'd also consider external features like weather, economic indicators, or events that might influence the target variable, ensuring they're available at prediction time.

I once had to explain why our fraud detection model was flagging legitimate transactions to the business team. Instead of diving into technical details about precision-recall trade-offs, I used analogies and visual aids. I compared it to airport security - being too strict catches more threats but inconveniences innocent travelers. I created simple charts showing the cost of missed fraud versus customer friction from false positives. I presented three model configurations as business scenarios: 'Conservative' (catches 95% of fraud, 2% false positives), 'Balanced' (90% fraud detection, 0.5% false positives), and 'Permissive' (85% fraud detection, 0.1% false positives). I quantified each scenario's financial impact in terms they understood - revenue loss, customer churn, and operational costs. This helped them make an informed decision about the acceptable trade-off. I also established regular reporting with business-friendly metrics and created a dashboard showing model performance in dollar terms rather than technical metrics.

During a computer vision project, I disagreed with a colleague who wanted to use a complex ensemble of multiple CNN architectures, while I advocated for a single, well-tuned ResNet model. Rather than dismiss their approach, I suggested we run a structured experiment. I proposed we both implement our solutions over a sprint, using the same dataset splits and evaluation metrics. I prepared a comparison framework looking at accuracy, training time, inference speed, memory usage, and maintenance complexity. My ResNet approach achieved 94.2% accuracy with 15ms inference time, while the ensemble achieved 94.8% accuracy but with 85ms inference time. I presented both results objectively, highlighting that the 0.6% accuracy gain came at a 5x latency cost, which wouldn't meet our production requirements. I acknowledged the ensemble's superior accuracy while demonstrating why it wasn't suitable for our use case. We decided to go with my approach, but I incorporated their suggestion of data augmentation techniques, which improved my model to 94.5% accuracy. This collaborative approach strengthened our working relationship and delivered a better final solution.