ML Interview Questions for Experienced: 7 Real Problems

In July 2026, a Blind survey of 1,552 India-based professionals asked one question: do you expect a layoff or a big headcount cut in the next three to six months? 66% of AI and ML workers said yes. In the same survey, only 24% of engineers called a cut "very likely", the lowest of any function. The survey did not ask about interviews, so what follows is my own reading: a nervous market makes interviewers look harder for proof of shipped work. Say the interviewer asks: your model scored well in the notebook but fails live. What do you check first? That is the kind of question this post prepares you for.

At 2+ years of experience, ML interviews test production judgment, not definitions. Expect to design a system under constraints, choose metrics that match the business goal, and explain why a live model got worse. Practise those three skills with the worked questions below, and fresher-level theory questions will take care of themselves.

Production judgment decides 2+ year ML interviews

A fresher is asked what an algorithm does, while a candidate with 2+ years is asked how to run one safely for real users.

My read is that the hiring market is part of why the bar feels higher. The survey only measures what workers expect, not how hard interviews are. Most who expect cuts point to quiet signals such as hiring freezes and budget cuts, while only 9% have seen a formal layoff announcement. In my experience, a quiet market means fewer open roles, and fewer roles means interviewers ask for proof that you have shipped things.

The same reports list the skills companies still want. Mint's coverage of the survey and the upGrad write-up both name generative AI, ML engineering, MLOps, model evaluation, data engineering and AI agents. Much of that list, such as MLOps and model evaluation, is about running models in production rather than training them.

Here is how the two levels differ in practice:

If the theory side still feels shaky, work through the machine learning interview questions for freshers first. Interviewers at this level still ask a few of them as warm-ups. For pay at the entry level in India, see the ML engineer fresher salary breakdown.

Design a recommendation system

This is the most frequent ML system-design question, and a strong answer starts with the constraints, not the model. Fahim ul Haq's list of ML system design interview questions puts it first, and his advice holds for the whole round: clarity beats complexity.

Say the prompt is "Design recommendations for a video app." Before you draw anything, ask four questions:

• Goal: are we raising watch time, clicks, or completed videos? Each one leads to a different model.
• Users: how many, and how many are brand new each day?
• Items: thousands of videos or millions? This decides the architecture.
• Latency budget: how fast must the home screen load?

With millions of items, you cannot score every video for every user in time. So you split the work into two stages. Candidate generation cheaply narrows millions of items down to a few hundred. Ranking then uses a heavier model to order those few hundred for this one user.

Propose a baseline before any deep model. "Most-watched videos in your region this week" is boring, but it gives you a number to beat. In my experience interviewers like it because it shows you can ship something on day one.

Then raise cold start yourself. A new user has no history, so show popular items or ask them to pick a few interests at sign-up. A new video has no views, so use its content features (title, category, creator) and keep a small slot in the feed for testing new items.

Expect follow-ups like these:

• How would you stop the feed from showing the same kind of video forever?
• How often do you retrain, and what triggers it?
• How do you handle a video that suddenly goes viral?
• What would you log to train the next version?

Design real-time fraud detection

Fraud detection tests whether you can balance a strict response-time limit against the cost of missing fraud versus blocking a good customer.

Take a UPI payment in India or a card payment in the US. The user taps "Pay" and expects an answer in a moment. Here is one payment moving through your system:

1. The payment request arrives with amount, merchant, device and location.
2. The service looks up features that already exist, such as this user's spending over the last day.
3. The model returns a fraud score.
4. A rule turns the score into approve, hold for review, or block.
5. The true label arrives later, when a customer reports fraud or a chargeback (the bank reverses the payment) comes in.

Step two hides the first trap. Only features available at request time are allowed. If your training data used a field filled in after the payment settled, the model learned from the future.

The second trap is class imbalance: fraud is a very small share of payments. Mention class weights (an extra penalty for mistakes on the rare class) or downsampling the normal cases. Then evaluate with precision and recall, never plain accuracy.

Precision versus recall is a business choice here. Missing fraud costs money. Blocking a real customer costs trust, and that customer may switch apps. Say you would agree the tradeoff with the product and risk teams, then set the threshold to match.

Close with the human-review fallback. Very high scores get blocked, very low scores pass, and the uncertain middle band goes to a reviewer. Reviewer decisions also become fresh labels for retraining.

Pick evaluation metrics and run an A/B test

The right metric is the one tied to the business result, and an A/B test is how you prove the model earned it.

Start with why accuracy misleads. When one class is rare, a model that always predicts "normal" scores high accuracy and catches nothing. Interviewers ask this to see if you notice.

Choose by the cost of each error. Use precision when a false alarm is expensive, like blocking a payment. Use recall when a miss is expensive, like a missed medical scan. Use F1 when both matter roughly equally. For recommendations, use ranking metrics such as precision at k or NDCG, a score that gives more credit the higher good items appear, so both reward putting good items near the top.

Then admit the gap. An offline metric measures predictions on old data. The business cares about revenue, retention or watch time on live traffic. A model can win offline and lose live, because users react to what they are shown.

That is why you run an A/B test. Set it up in four parts:

• Control group: users who keep the current model.
• Sample size decided in advance: work it out before launch, so you do not stop early on a lucky day.
• Guardrail metric: something that must not get worse, like page load time or complaints.
• Test length: at least one full week, so weekday and weekend behaviour are both included.

This skill is worth the practice time. Model evaluation sits on the in-demand skills list from the upGrad report.

Detect drift in a live model

Monitoring questions ask how you would notice that a model has quietly gotten worse after launch.

Name the two kinds first. Data drift means the inputs change: a new city launches, and the age mix of users shifts. Concept drift means the meaning of the target changes: fraudsters find a new trick, so yesterday's "safe" pattern is now risky.

Monitor three layers:

• Input distributions: compare each important feature against its training values.
• Prediction distribution: a sudden jump in the share of "fraud" scores is a warning, even before labels arrive.
• Delayed ground truth: when real labels come in, compute the real metric and compare it with launch.

Interviewers often ask how you measure input drift. The population stability index (PSI) is a common answer. It splits a feature into buckets and compares how values spread across those buckets in training versus live data:

import numpy as np
def psi(train_values, live_values, bins=10):
    # Bucket edges come from the training data
    edges = np.quantile(train_values, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf
    train_pct = np.histogram(train_values, edges)[0] / len(train_values)
    live_pct = np.histogram(live_values, edges)[0] / len(live_values)
    # Avoid dividing by zero or taking log of zero
    train_pct = np.clip(train_pct, 1e-6, None)
    live_pct = np.clip(live_pct, 1e-6, None)
    return np.sum((live_pct - train_pct) * np.log(live_pct / train_pct))

A higher value means the live data looks less like training data. A PSI near zero means the two match closely; comparing a feature with itself gives exactly 0. For the alert threshold, say you would measure PSI over a few weeks of normal traffic and alert when it moves well outside that range. Then describe the retraining trigger: a drift alert alone starts an investigation, but a confirmed drop in the real metric starts retraining.

Explain a model that works offline but fails live

This model-behavior question checks whether you can debug the gap between a notebook score and real traffic.

Say your model scored well in the notebook, and two days after launch the business metric has dropped. Walk through the causes in this order, because the first ones are the most common and the quickest to check:

Interviewers want the order as much as the list. Starting with "retrain on more data" before checking skew tells them you guess before you measure.

Build a feature store and training pipeline

These MLOps questions test whether your training and serving code can share the same features and be rerun reliably.

A feature store solves the skew problem from the last section. Each feature, like "payments in the last hour", is defined once. Training reads its history, serving reads its latest value, and both use the same code. Versioning lets you see exactly which feature definitions a given model was trained on.

For the pipeline, interviewers expect stages like these:

1. Data validation: check schema, missing values and ranges before training starts.
2. Training: train with fixed code and data versions, so the run can be repeated.
3. Evaluation gate: the new model must beat the current one on agreed metrics, or it stops here.
4. Model registry: store the model with its data version, features and scores.
5. Deploy: release to a small share of traffic first, then widen.

Then answer the rollback question before they ask it. Because the registry keeps the previous model, rollback means pointing the service back at that version. That is a config change, not a retraining job. MLOps is on the same in-demand skills list as evaluation, so expect at least one question from this area.

Practise one project as a design answer

Start with the one system-design question closest to work you have already done, then widen to the rest. Real details from your own project make answers sound specific and believable, and in my experience interviewers notice.

1. Pick one past project

   Choose the ML project you know best, even a small one.

2. Rewrite it as a design answer

   Start with goal, users, data size and latency, then the baseline you would ship first.

3. Add metrics

   Name the offline metric, the live business metric, and how an A/B test would connect them.

4. Add a drift plan

   Say what you would monitor, where the alert sits, and what triggers retraining.

5. Do a timed mock out loud

   Speak the answer to a friend or a recording. Writing it is not the same as saying it.

For how experienced-level rounds run in other areas, the Node.js questions for 5 years of experience and this Amazon SDE interview experience show the same shift from definitions to design.

Your next step: pick one ML project you have built, write a one-page system-design answer for it covering constraints, metrics and a drift plan, then say it out loud in a ten-minute mock interview this week. Check it against the freshers post for any theory gaps. Which of these seven questions would you find hardest to answer right now?