ML Engineer Interview FAQs Most Asked Questions in 2026

Bias is error from overly simple assumptions — the model misses real patterns (underfitting). Variance is error from being too sensitive to the training data — the model fits noise (overfitting). Good models balance both. Regularisation, more data, and ensemble methods usually reduce variance; richer models reduce bias.

Precision matters when false positives are expensive (spam filters, fraud alerts for customers). Recall matters when false negatives are expensive (cancer detection, fraud detection, security alerts). When both matter, use F1 or PR-AUC — and always look at the cost of each error type before choosing.

Regularisation adds a penalty on model complexity during training. L1 (Lasso) encourages sparse solutions — useful for feature selection. L2 (Ridge) shrinks coefficients — useful against overfitting. ElasticNet combines both. Dropout is regularisation for neural networks. The mechanism is always the same: discourage the model from fitting noise.

Gradient descent is an optimisation algorithm that updates model parameters in the direction that reduces the loss. It computes the gradient of the loss with respect to the parameters, then steps in the opposite direction (downhill). Variants (SGD, Mini-batch, Adam) differ mainly in how many samples they use per step and how the step size adapts over time.

Cross-validation (k-fold) gives a more reliable estimate of generalisation error than a single train/test split. It reduces the chance of getting a lucky or unlucky split, and it helps detect overfitting to a small validation set. For time-series data, use time-series CV instead of random k-fold.

In 2026 the biggest wins still come from good features: domain-informed transforms, interactions, time-based aggregations, and well-handled categoricals (target encoding done carefully, or embeddings). Leakage is the most common mistake — never use information that would not be available at prediction time.

AUC is the probability a random positive is ranked higher than a random negative. Sort by score, iterate through negatives and positives, and accumulate. In practice most interviews accept sklearn.metrics.roc_auc_score, but they want you to explain what it means and why it is preferable to accuracy for imbalanced data.

First, understand why data is missing — is it MCAR, MAR, or MNAR? Simple options: drop rows, drop columns, mean/median/mode imputation. Better options: model-based imputation (IterativeImputer), indicator columns for missingness, or domain-specific defaults. Never impute blindly — the method interacts with the model and the business context.

df['ma'] = df['value'].rolling(window=7).mean(). Mention handling gaps with min_periods, using ewm for exponential weighted averages, and the fact that the first N-1 values will be NaN unless you fill them.

First, decide whether outliers are errors or genuine signals. Statistical approaches: IQR, z-score, MAD. Model-based: Isolation Forest, Local Outlier Factor. Handling options: remove (only if errors), clip (winsorize), transform (log), or use robust models that tolerate them. Always check the impact on the final model.

Python, pandas, numpy, scikit-learn, and one deep learning framework (PyTorch in most 2026 interviews). For MLOps: Docker, MLflow, a cloud SDK (AWS/GCP/Azure). For pipelines: Airflow or Dagster. For serving: FastAPI or TorchServe. Be honest — depth in a few tools beats surface-level in many.

Start from problem framing (what business metric, what users, what constraints). Then layers:

1. Candidate generation — collaborative filtering, matrix factorisation, embeddings.
2. Ranking — gradient boosted trees or deep models on user + item features.
3. Re-ranking — business rules, diversity, freshness.
4. Feedback loop — click/convert signals feeding training data.
5. Monitoring — CTR, coverage, latency, drift.

Emphasise trade-offs: latency vs accuracy, cold start, online vs batch training, and how you would A/B test.

Fraud is a real-time, highly imbalanced, adversarial problem. Cover:

• Data — transaction, user history, device, network features.
• Model — gradient boosting with strong class reweighting; graph features for collusion.
• Real-time scoring — sub-100ms budget, streaming features.
• Feedback — label delays, manual review queues.
• Adversarial drift — monitoring and retraining cadence.

Describe the pipeline: data extraction from warehouse → feature computation (same as serving features!) → training job → offline evaluation → model registry → deployment gate → canary rollout. Use Airflow or Dagster for orchestration, MLflow for tracking, and store datasets with versioning (DVC or lakehouse tables). Address idempotency, backfills, and how training handles missing data days.

Batch is simpler, cheaper, and easier to monitor. Real-time is required when predictions depend on fresh user context (session recommendations, fraud scoring, dynamic pricing). The decision is usually driven by feature freshness + latency requirement + cost. Hybrid (near-real-time with short batching) is often the right answer.

Three layers:

• System — latency, error rate, throughput, resource usage.
• Data — schema drift, null rates, distributions of key features.
• Model — prediction distribution, accuracy on delayed labels, business KPIs (CTR, conversion, fraud caught).

Alert on drift metrics (PSI, KS), on business metric drops, and on input anomalies.

Data drift is when the distribution of inputs changes in production vs training. Detection: PSI, KS test, Chi-square for categoricals, distribution comparison plots. Concept drift is when the relationship between inputs and outputs changes — harder to detect; requires delayed labels or proxy metrics. Response: investigate, retrain, or change features.

Models: model registry (MLflow, SageMaker Model Registry) with versioned artifacts, metadata, and stage (staging/prod/archive). Datasets: versioned snapshots or lakehouse tables (Delta, Iceberg), or DVC for file-based datasets. Always link model version to dataset version and code commit — that's the reproducible triplet.

Common causes: train-serve skew (different feature computation), label leakage offline, distribution shift, feedback-loop bias, or genuine adversarial behaviour. Investigate in order:

1. Compare online vs offline feature distributions.
2. Verify training labels correspond to same-time features.
3. Check data collection pipelines for missing values.
4. Shadow-deploy and compare predictions to the baseline.

Use the STAR format: situation, task, action, result. Pick a real example. Show that you identified the failure, investigated the cause, and fixed it — including what you would do differently. Interviewers are looking for ownership and learning, not perfection.

Three gates: offline metrics beat the current baseline with statistical significance, offline behaviour matches expected distributions across segments (no fairness or coverage regressions), and the risk is understood well enough to A/B-test safely. Talk about canary rollout, business metric holdout, and rollback plans.

Concretely: agree with data scientists on metric definitions and evaluation criteria before training; work with backend to align feature computation for training and serving; partner with product on the business metric and rollout plan. Show that you have lived the "boundary" conversations — not just talked about them.

Pick a project where you had end-to-end ownership. Describe the problem, the constraint (data, latency, cost), the design decision you made, the metric you moved, and what you learned. End with a concrete number — "we shipped X and it moved Y by Z%" — that is what stays in the interviewer's mind.

Be specific. Mention the paper, course, library, or project you are actively working on — and why. Vague answers like "I'm following AI" are a red flag. Even a small project or a course you are halfway through is far more impressive than buzzwords.

Data Scientists explore data, build models, and communicate insights. ML Engineers take models into production — building pipelines, serving infrastructure, monitoring, and retraining. There is overlap, but ML Engineers own reliability and scale.

Consistency is key: features must be computed the same way in training and serving. Use a feature store (Feast, Tecton) or a shared feature library. Document feature lineage, and monitor each feature's distribution in production.

First, check whether accuracy is the right metric — often it is not. Use PR-AUC, F1, or cost-sensitive metrics. Then, options: class weights, resampling (SMOTE done carefully), threshold tuning, or using a model that handles imbalance well (tree ensembles). Avoid blindly oversampling — it can introduce leakage.

Split users randomly into control and treatment, define primary and secondary metrics up front, compute the required sample size for statistical power, run for a full business cycle (usually 2 weeks), and check guardrail metrics (latency, error rate). Report the effect size with confidence intervals, not just p-values.

Complex models (deep nets, boosted ensembles) often win on accuracy but are hard to explain. Interpretable models (linear, small trees, rule-based) are easier to debug and audit — which matters in regulated industries like finance and healthcare. The right balance depends on the business requirement and the cost of a wrong prediction.

Typically 4-6 rounds: a recruiter screen, a coding round, one or two ML theory rounds, an ML system design round, an MLOps round, and a behavioral round. Product companies usually include a project deep-dive. Startups may compress rounds to 3-4.

You need to be comfortable with linear algebra (vectors, matrices), probability (distributions, Bayes), and calculus (gradients). You do not need research-level mathematics — understanding the intuition behind gradient descent, loss functions, and regularisation is usually enough.

Practice 4-5 classic problems — recommendation, fraud detection, search ranking, feed, and ad click prediction. For each, be able to describe: data sources, feature pipeline, model choice, serving architecture, monitoring, and trade-offs. Draw diagrams while you speak.

Yes — 2-3 solid projects are far more valuable than ten shallow ones. Ideal: one project demonstrating data engineering, one showing model development with business impact, and one showing deployment + monitoring. Document each on GitHub.

If you already have ML foundations: 4-8 weeks of focused prep (coding practice, system design, project stories, mock interviews). If you're coming from a different field, plan 3-6 months of preparation alongside building real projects.