A machine learning engineer closes the gap between research and production: they take data, build and evaluate models, and ship those models to users in reliable, monitored systems. This guide covers exactly what the role demands, what interviewers test, and how to get hired in 2026.
What an ML engineer does day-to-day
Machine learning engineers own the entire arc from data to deployed model. On any given day that might mean writing feature-engineering code for a new signal, running a training experiment with different hyperparameters, reviewing offline evaluation metrics, debugging a latency regression in the serving layer, or investigating why a model that looked good in validation is misbehaving in production.
Unlike a data scientist, an ML engineer is responsible for putting the model into production and keeping it healthy there. Unlike an MLOps engineer, they own the model itself - the architecture, the training code, the loss function, and the offline evaluation. The boundary shifts by company size: at startups, one person often does both.
Skills companies expect
ML engineer job descriptions cluster around a core skill set that scales in depth with seniority. Junior roles weight strong Python and ML fundamentals; senior roles add system design, production debugging, and the ability to evaluate architectural trade-offs without a manager involved.
| Skill area | What you need to know | Tools commonly asked about |
|---|---|---|
| Python | Proficiency beyond notebooks: packaging, testing, type hints, async, profiling | pytest, Poetry, mypy |
| ML frameworks | Training loops, custom layers, dataloaders, GPU utilisation | PyTorch (primary), TensorFlow, JAX |
| Classical ML | Gradient boosting, SVMs, linear models, decision trees - the algorithms, not just the API calls | scikit-learn, XGBoost, LightGBM |
| Feature engineering | Encoding, imputation, scaling, time-series features, embedding lookups | pandas, Polars, Feature Store |
| Evaluation | Metric choice for imbalanced classes, calibration, offline vs online metrics, A/B testing | scikit-learn, W&B, MLflow |
| Experiment tracking | Logging parameters, metrics, artifacts; comparing runs; reproducibility | MLflow, Weights & Biases, DVC |
| Model serving | REST/gRPC endpoints, batching, ONNX export, latency budgets | FastAPI, Triton, TorchServe |
| SQL + data | Joining large tables for feature generation, window functions, query plans | BigQuery, Snowflake, Spark |
The interview process
ML engineer loops typically run 4-5 rounds and weight ML knowledge and system design more heavily than a standard software engineering loop. Coding is tested but usually at mid-level algorithmic complexity rather than competitive-programming depth.
- 1
Recruiter and technical screen
Round 130-45 minResume walkthrough, motivation, and a light ML warm-up: gradient descent variants, bias-variance, overfitting. Some companies send a take-home at this stage - typically a small Kaggle-style problem to solve and submit within a few days. - 2
ML knowledge round
Round 245-60 minCore ML theory tested conversationally: regularisation, cross-validation, class imbalance, gradient boosting vs neural networks, attention mechanisms, and how you would evaluate a model for a given business problem. Interviewers are checking depth, not recall - they want to see you reason, not recite. - 3
Coding round
Round 360 minPython-heavy: numpy/pandas manipulation, implementing a model or evaluation metric from scratch, or algorithmic problems at the medium-LeetCode level. Some companies ask you to implement logistic regression or k-means without a library to test whether you understand what the API is doing. - 4
ML system design
Round 460 minDesign a complete ML system for a given problem - a recommender, a fraud detector, a search ranker. You are expected to cover data collection, feature engineering, model choice, offline evaluation, deployment strategy, and production monitoring. This is the most differentiating round at senior and above. - 5
Behavioral
Round 530-45 minCross-functional collaboration with data scientists and engineers, handling tradeoffs between model accuracy and serving cost, dealing with ambiguous business requirements. STAR format. Increasingly, senior ML loops add a presentation of your most impactful project.
Common interview questions
ML fundamentals
- Explain the bias-variance tradeoff. Bias is error from wrong assumptions in the model (underfitting); variance is error from sensitivity to small fluctuations in training data (overfitting). Reducing one tends to increase the other. Regularisation, dropout, early stopping, and ensemble methods are the levers to manage it.
- How do you handle severe class imbalance? Resampling (SMOTE, undersampling the majority), class weights in the loss function, using precision-recall AUC rather than accuracy as your metric, and calibrating the model so predicted probabilities are meaningful at the threshold you care about.
- When would you use gradient boosting vs a neural network? Gradient boosting (XGBoost, LightGBM) wins on structured/tabular data with limited data and a need for fast training and interpretability. Neural networks win when data is abundant, the structure is spatial or sequential (images, text, audio), or when transfer learning via pretrained models is available.
- What causes training-serving skew? The feature computation at training time differs from the computation at serving time - different code paths, different data sources, or offline preprocessing that is not replicated online. Prevention: shared feature logic (ideally a feature store) and automated parity tests that compare training-time and serving-time feature values on the same input.
- What is the difference between online and offline metrics? Offline metrics (AUC, RMSE) are measured on historical data before deployment. Online metrics (click-through rate, conversion, revenue) are measured in production via A/B tests. A model can improve offline metrics while hurting online ones - the gap is usually a distribution shift or a mismatch between what the model was trained to predict and what the business actually cares about.
Deep learning
- Explain the attention mechanism in transformers. Attention computes a weighted sum of all tokens in the sequence, where the weight for each token pair is derived from the dot product of their query and key vectors, scaled and softmax-normalised. This lets each output token attend to every input token in O(n²) time, capturing long-range dependencies that RNNs struggle with.
- What is gradient clipping and why does it matter? Clipping the gradient norm to a maximum value before each update prevents exploding gradients in deep networks and RNNs. Without it, a single bad batch can produce a parameter update so large it moves the model far into a high-loss region from which training may not recover.
- How do you debug a training run that isn't converging? Check in order: (1) data pipeline - are labels correct, is there data leakage? (2) loss curve - is it decreasing at all, or completely flat? (3) learning rate - try 10x smaller; (4) batch size; (5) gradient norms - log them; (6) weight initialisation. Overfit a single batch first to confirm the network can learn at all.
ML system design topics
ML system design interviews test whether you can architect a complete solution to a business problem - from data ingestion to production monitoring. The key distinction from standard system design is that you must address the probabilistic, stateful nature of models and the feedback loops that keep them healthy.
- Design a recommendation system for a streaming platform or e-commerce site. Cover retrieval (candidate generation), ranking (a pointwise or pairwise model), filtering (business rules), and how you evaluate and iterate offline and online.
- Design a real-time fraud detection system. Low-latency serving (sub-10ms), streaming features from transactions, handling severe class imbalance, the cost asymmetry between false positives and false negatives, and the feedback loop from human review labels.
- Design a search ranking model. Query understanding, document feature extraction, learning-to-rank (pairwise, listwise), offline evaluation via NDCG, and A/B testing online against a baseline ranker. How do you handle position bias in your training data?
- Design a training pipeline for a large model. Distributed training (data parallel vs model parallel), gradient accumulation, checkpointing, experiment tracking, automated evaluation gates before a model can be promoted to production.
Coding expectations
Most ML engineer coding rounds test Python proficiency and mid-level algorithmic thinking - not competitive programming. The most common patterns: array/matrix manipulation, two pointers, sliding window, hash maps, and tree traversal. Some companies also ask you to implement an ML primitive without a library.
- numpy from scratch: implement a dot product, matrix multiply, softmax, or cosine similarity using only basic Python. Tests whether you understand what the library is doing.
- Implement logistic regression or k-means. Write the training loop, gradient computation, and prediction function. Not because you'll do this in production, but because it confirms you understand the algorithm rather than just calling
fit(). - Data manipulation: pandas/polars questions on groupby, merge, rolling windows, and reshaping. Common in roles that touch feature engineering.
- Algorithmic medium: the equivalent of LeetCode medium - two-sum variants, sliding windows, BFS/DFS on a graph. Rarely goes to hard-level graph algorithms or dynamic programming.
Salary ranges by region
ML engineering commands a premium over general software engineering across every market because the combination of production engineering skills with deep ML knowledge is still relatively scarce. Figures below are approximate median total compensation (base + bonus + equity), blended across company sizes. AI lab and big-tech offers sit materially above these in every market.
30/60/90-day plan
Whether you are joining as a new hire or transitioning into an ML engineering role, the first three months follow a clear arc: understand the existing system, close one gap, then own something end-to-end.
- 1
First 30 days - map what exists
LearnMonth 1Understand every model in production: what it predicts, how it was trained, what features it uses, how it is deployed, and what is monitored. Trace one feature from raw data to the model input. Identify the biggest risk - the model with no monitoring, the pipeline with manual steps, or the feature with a training-serving discrepancy. - 2
First 60 days - own a model improvement
BuildMonth 2Run a structured experiment on an existing model: add a new feature, try a different architecture, tune hyperparameters with a principled sweep. Set up proper offline evaluation before you start - NDCG, AUC, or whatever metric maps to the business goal. Ship the improvement through the deployment pipeline, with before and after metrics. - 3
First 90 days - own a model end-to-end
OwnMonth 3Design and ship a training-to-serving pipeline for either a new model or a full redesign of an existing one - with tracked experiments, an automated evaluation gate, a deployment story, and production monitoring. This is the signal that you can operate independently as an ML engineer.
Common mistakes ML engineers make
- Optimising offline metrics without aligning them to business outcomes. AUC on a held-out test set is not a proxy for revenue. Before you start modelling, verify that your offline metric correlates with the online metric you actually care about. If it doesn't, no amount of model tuning will move the needle.
- Data leakage in training. Features that are computed using information that would not be available at prediction time are the single most common reason a model that looks great offline performs poorly online. Audit your feature computation pipeline with the question: "would this value exist at the moment of prediction?"
- Not tracking experiments. Running experiments without logging parameters, data versions, and metrics means you cannot reproduce your best result or explain why one run outperformed another. Set up MLflow or W&B on day one, not when the team grows.
- Shipping a model with no monitoring. Models degrade silently. Production data distributions drift. Without monitoring prediction distributions and key business metrics post-deployment, you will not know when a model has stopped working until users or business stakeholders tell you - weeks or months later.
- Skipping the baseline. A well-tuned heuristic or a simple logistic regression will often beat a deep neural network on smaller datasets and structured data. Start simple, measure it, and only add complexity when you can show it improves the metric that matters.
ML engineer vs related roles
The boundaries between ML engineering, data science, AI engineering, and MLOps shift by organisation size and maturity. At a startup of ten people they might all be the same job. At a large tech company they are distinct specialisations with separate interview loops and compensation bands.
| Dimension | ML Engineer | Data Scientist | AI Engineer | MLOps Engineer |
|---|---|---|---|---|
| Primary focus | End-to-end model: data to production | Analysis, insight, experimentation | Building products on top of pretrained models | Deployment, pipelines, and model operations |
| Trains models from scratch | Yes - core of the role | Often, but may hand off to engineering | Rarely - uses APIs and fine-tuning | No - operates them |
| Production ownership | Yes - including serving and monitoring | Varies - often hands off | Yes - end-to-end product | Yes - infrastructure layer |
| Core tooling | PyTorch, scikit-learn, pandas, MLflow | Python, R, SQL, notebooks, BI tools | LLM APIs, LangChain, vector DBs, RAG | Airflow, Kubernetes, SageMaker, Terraform |
| Typical scope | Model + pipeline for a specific product area | Analysis project or model for a business question | LLM-powered product feature or agent | The ML platform and deployment infrastructure |
Related guides: AI Engineer vs ML Engineer for a detailed side-by-side of the two roles; MLOps Engineer for the operational side of the ML house; and System Design Fundamentals for the infrastructure concepts every ML engineer needs to know going into system design rounds.
Sources & further reading
- 1Machine Learning Roadmap ā roadmap.sh
- 2Designing Machine Learning Systems ā Chip Huyen (O'Reilly)
- 3Software engineer compensation data by level and location ā levels.fyi
- 4PyTorch documentation - tutorials and concepts ā PyTorch