Why machine learning interviews feel different

If you have interviewed for a software engineering role before, a machine learning interview will feel familiar and strange at the same time. There is still a coding round. There is still a behavioral conversation. But mixed in with those, you will be asked to explain why a model overfits, how you would evaluate a classifier when the classes are imbalanced, or how you would design a recommendation system that serves millions of users with a latency budget measured in milliseconds. The mixture can feel unpredictable because the field itself is a mixture: part software engineering, part statistics, part applied research, part product thinking.

There is no single official syllabus for machine learning interviews, and the mix varies by company, by seniority, and by whether the role is called machine learning engineer, applied scientist, research scientist or data scientist. That said, across enough interview loops a recognizable pattern shows up often enough to be useful. This article walks through that pattern, area by area, with worked examples so you can see exactly what a good answer looks like and why it works, not just a list of topics to memorize.

The five areas a typical loop tests

Most ML interview loops, when you add up all the rounds, end up probing five things. Not every loop covers all five, and junior roles often skip the system design round, but if you prepare for these five you will be ready for the large majority of what comes up.

  • Coding and data structures, often with a data or numerical flavor
  • Machine learning fundamentals and theory, tested through questions and short derivations
  • Applied ML case studies, where you reason through building a model for a real problem
  • ML system design, where you design a full production pipeline, not just a model
  • Behavioral interviews, which check communication, collaboration and judgment

The rest of this article takes each of these in turn, with concrete examples and worked numbers so the ideas are not abstract.

Coding and data structures: what interviewers are really checking

It is not a test of memorized algorithms

The coding round in an ML interview usually looks like a standard software engineering coding question, but two things are different in practice. First, many ML teams care about whether you can write correct, reasonably efficient code and explain your reasoning as you go, rather than whether you recall a specific trick. Second, because ML engineers spend a lot of time manipulating arrays, data frames and tensors, some interviewers choose problems that reward vectorized thinking over explicit loops, since that mirrors the day-to-day work with libraries such as NumPy or pandas.

Consider a problem that comes up in some form across many ML coding rounds: compute the moving average of a sequence of numbers over a fixed window. It sounds simple, but it tests whether you reach for an efficient, vectorized solution or write a slow nested loop, and whether you handle edge cases such as a window larger than the data.

🐍Python
import numpy as np

def moving_average(values, window):
    values = np.asarray(values, dtype=float)
    if window <= 0 or window > len(values):
        raise ValueError("window must be between 1 and len(values)")
    cumsum = np.cumsum(np.insert(values, 0, 0))
    return (cumsum[window:] - cumsum[:-window]) / window

data = [10, 12, 13, 12, 15, 19, 20, 18, 17, 16]
print(moving_average(data, 3))

This code assumes NumPy (tested with versions in the 1.x and 2.x series, the functions used here have been stable across both). It computes a prefix sum with cumsum, then subtracts the prefix sum at the start of each window from the prefix sum at the end, dividing by the window size. For the data above with a window of 3, the output is an array of eight values, the first being the average of 10, 12 and 13, which is 11.667, and the last being the average of 20, 18, 17, 16 taken over the correct three-element window ending at the last index. Each value in the array is the average of three consecutive numbers, and the array is shorter than the input by window minus one elements, which is exactly what you would expect when every output needs a full window behind it.

What an interviewer is listening for here is not just a correct answer. They want to see you notice that a naive double loop would be O(n times window) and that the cumulative sum trick brings it down to O(n). They also want to see you handle the edge case where the window is larger than the data, which the ValueError check does. In an ML context, being fluent with this kind of array manipulation matters because feature engineering pipelines are full of rolling statistics, grouped aggregations and reshaping operations, and a candidate who reaches instinctively for loops over large arrays is a candidate who will write slow pipelines in production.

A second, closely related style of question asks you to implement a small piece of a learning algorithm by hand, such as one step of gradient descent for linear regression. This checks whether you actually understand what a library like scikit-learn is doing under the hood, rather than only knowing how to call fit and predict.

🐍Python
import numpy as np

# synthetic data: true relationship is y = 3x + 7, plus noise
rng = np.random.default_rng(seed=0)
x = np.linspace(0, 10, 50)
y = 3 * x + 7 + rng.normal(0, 1, size=x.shape)

# add a column of ones for the intercept term
X = np.column_stack([np.ones_like(x), x])

def gradient_descent(X, y, lr=0.01, n_iter=2000):
    n, d = X.shape
    w = np.zeros(d)
    for _ in range(n_iter):
        preds = X @ w
        error = preds - y
        grad = (2 / n) * (X.T @ error)
        w = w - lr * grad
    return w

w = gradient_descent(X, y, lr=0.01, n_iter=2000)
print("intercept, slope:", w)

Run with the seed fixed at 0, this should converge to values close to the true intercept of 7 and slope of 3, something like an intercept near 7 and a slope near 3, with small deviations because of the added noise and because 2000 iterations at a learning rate of 0.01 may not reach the exact minimum. If you tried a much larger learning rate, such as 1.0, the weights would likely diverge instead of converging, because the gradient step would overshoot the minimum each time. If you forgot to scale the features and the input ranged over, say, 0 to 10,000 instead of 0 to 10, the same learning rate that worked here could easily diverge, because the gradient scale depends on the scale of the inputs. Interviewers often probe exactly this: what happens if the learning rate is too high, or if you do not normalize your features. Being able to answer that from first principles, rather than reciting a rule, is what separates a strong answer from a memorized one.

Machine learning fundamentals: the core conceptual check

This is the part of the interview that most clearly separates candidates who have internalized the concepts from candidates who have only used libraries. The good news is that a relatively small set of ideas, understood deeply, covers most of what gets asked: the bias-variance tradeoff, evaluation metrics, regularization, and the assumptions behind common models. We will work through each with numbers.

Bias and variance, with numbers

Imagine you are fitting a polynomial to some noisy data, and you try three different model complexities. You measure the error on the training set and on a separate test set.

  • A degree-1 polynomial (a straight line): training error 18%, test error 19%
  • A degree-3 polynomial: training error 6%, test error 8%
  • A degree-15 polynomial: training error 1%, test error 35%

The degree-1 model is too simple to capture the real pattern in the data, so it performs poorly on both the training set and the test set. This is high bias, also called underfitting: the model's assumptions are too rigid for the true relationship, and more data would not fix this, because the model simply cannot represent the pattern no matter how much data you feed it. The degree-15 model does the opposite: it fits the training data almost perfectly, including its noise, but that noise does not generalize, so test error is far worse than training error. This is high variance, also called overfitting: the model is sensitive to the specific sample it was trained on. The degree-3 model sits in between, with training and test error both reasonably low and reasonably close to each other, which is the sign of a good fit for this particular problem.

The tradeoff is named well: reducing bias (by adding model complexity) tends to increase variance, and reducing variance (by simplifying the model, adding regularization, or gathering more data) tends to increase bias, up to a point. In an interview, a strong answer does not just name the terms. It explains what evidence from training and test error tells you about which regime you are in, and what specific remedy follows: more data or regularization for high variance, more features or a more flexible model for high bias.

Evaluation metrics, with a worked confusion matrix

Suppose you build a fraud detection model and evaluate it on 1,000 transactions, of which 100 are actually fraudulent. Your model flags 120 transactions as fraud. Of those 120 flagged, 70 are truly fraudulent and 50 are not. Of the 100 truly fraudulent transactions, this means 70 were caught and 30 were missed.

  • True positives (TP): 70, correctly flagged fraud
  • False positives (FP): 50, flagged as fraud but actually legitimate
  • False negatives (FN): 30, actual fraud that was missed
  • True negatives (TN): 850, correctly left unflagged

Accuracy here would be (70 + 850) / 1000 = 92%, which sounds impressive, but it is misleading, because a model that never flags anything as fraud would score 90% accuracy by doing nothing useful at all, since fraud is only 10% of the data. This is exactly why interviewers ask about imbalanced classes: accuracy hides the thing you actually care about.

Precision answers: of the transactions we flagged, how many were actually fraud. Here precision is 70 / (70 + 50) = 70 / 120, which is about 0.583, or 58.3%. Recall answers: of the actual fraud cases, how many did we catch. Here recall is 70 / (70 + 30) = 70 / 100 = 0.70, or 70%. The F1 score is the harmonic mean of the two, which penalizes a model that is very strong on one and very weak on the other: 2 times 0.583 times 0.70, divided by (0.583 plus 0.70), which works out to roughly 0.636, or 63.6%.

Which metric matters depends entirely on the cost of each type of error, and this is the part interviewers most want to hear you reason through out loud. If missing a fraudulent transaction is very costly (a large financial loss) but a false alarm is cheap (a customer gets a text message to confirm a purchase), you would favor recall, even if it costs you some precision. If false alarms are expensive (a legitimate customer's card gets blocked and they churn), you would weigh precision more heavily. A good answer names the business tradeoff explicitly instead of defaulting to F1 or accuracy as a reflex.

Regularization: why more parameters is not free

Regularization adds a penalty to the loss function based on the size of the model's weights, which discourages the model from relying too heavily on any single feature and tends to reduce variance. In linear regression, L2 regularization (ridge regression) adds a term proportional to the sum of squared weights to the loss, and L1 regularization (lasso) adds a term proportional to the sum of absolute values of the weights. A practical difference worth knowing: L1 regularization tends to push some weights all the way to zero, effectively performing feature selection, while L2 regularization shrinks weights toward zero without usually making them exactly zero. If an interviewer asks why you might prefer lasso over ridge, a concrete answer is that you suspect many of your features are irrelevant and you want the model to effectively discard them, producing a simpler, more interpretable model.

Applied ML case studies: reasoning through a real problem

A case study question usually sounds open-ended, something like: a subscription company wants to predict which customers will cancel next month, and gives you a dataset of customer activity. Walk me through your approach. These questions are less about producing a single correct answer and more about watching how you structure an ambiguous problem.

A strong answer usually moves through a sequence like this. First, clarify the business objective: does the company want to identify customers to target with a retention offer, or simply to forecast revenue? These lead to different choices later. Second, look at the label: how is churn defined, over what window, and is the dataset balanced? In most churn problems, churners are a minority, perhaps 5% of customers in a given month, which immediately raises the same imbalance issue discussed in the metrics section: accuracy will be misleading, and you should propose precision, recall or a cost-weighted metric aligned with what a retention offer actually costs versus what a missed churner costs.

Third, think carefully about data leakage, which is one of the most common pitfalls interviewers are watching for. If the dataset includes a column like "support ticket mentioning cancellation" or "account status at end of month," using it as a feature would leak information from the future into the prediction, since that information would not be available at the time you actually need to make the prediction. A candidate who spots this and asks "when, exactly, would this feature be known relative to the prediction time" is demonstrating exactly the kind of care that separates someone who has only read about models from someone who has shipped one.

Fourth, think about how to split the data. For most churn-style problems, a random split is the wrong choice, because it lets information from the future leak into training through customers whose behavior is correlated over time with other customers in the test set, and because the real deployment scenario is always: train on the past, predict the future. A time-based split, where you train on data up to a certain month and test on the following month, matches how the model will actually be used.

Fifth, propose a simple baseline before reaching for a complex model: a model that always predicts the majority class, or a simple rule like "flag customers whose usage dropped by more than 50% in the last month," gives you a reference point. Only after establishing that baseline does it make sense to discuss logistic regression, gradient boosted trees, or anything more elaborate, and the choice should be justified by the nature of the features (tabular data with mixed types usually favors tree-based models over deep learning, for instance) rather than by reaching for whatever is currently fashionable.

ML system design: zooming out from the model to the system

System design questions ask you to design something like a recommendation system, a search ranking system, or a spam filter, end to end. This round exists because building a model that performs well on a held-out test set is a small part of making something that works in production, and many candidates who are strong on theory have never had to think about how a model is actually served, monitored and retrained.

A reliable structure for answering these questions is to work through a consistent sequence of steps, narrating your reasoning at each one rather than jumping straight to an architecture diagram.

  • Clarify the goal and constraints: what is being optimized, what scale and latency are required, what data already exists
  • Define the data: what signals are available, how fresh they are, and what the label actually represents
  • Choose features and a modeling approach appropriate to the constraints
  • Describe the training and serving architecture, including how predictions reach the user in time
  • Define offline and online evaluation, and how success will actually be measured after launch
  • Describe monitoring and the feedback loop that lets the system improve over time

Working through a concrete example makes this less abstract. Say the question is: design a system that recommends the next video to a user on a streaming platform. Clarifying the goal first matters because "maximize clicks" and "maximize watch time" lead to different systems; a system optimized purely for clicks will favor clickbait thumbnails over videos people actually finish watching, so you would push toward a goal closer to watch time or a combination of engagement signals, while flagging that the choice has real consequences for content quality.

On data, you would note the available signals: watch history, search queries, explicit ratings if they exist, and implicit signals like skip rate or rewatches. You would also flag the cold start problem explicitly: a new user with no history, and a new video with no engagement data, both need a strategy, such as falling back to popularity-based or content-based recommendations until enough interaction data accumulates.

On modeling, a common and defensible architecture for recommendation at scale is a two-stage design: a candidate generation stage that quickly narrows millions of videos down to a few hundred plausible candidates for a given user, often using an efficient method like matrix factorization or approximate nearest neighbor search over learned embeddings, followed by a ranking stage that takes those few hundred candidates and scores them with a more expensive model that can use richer features, since it only has to score hundreds of items rather than millions. Explaining why this two-stage split exists, namely that a single model accurate and rich enough to rank the full catalog directly would be too slow to run within a latency budget of, say, under 200 milliseconds per request, shows the interviewer you are reasoning about real constraints rather than reciting an architecture by name.

On evaluation, you would distinguish offline metrics you can compute on historical data, such as precision at k or a ranking metric like normalized discounted cumulative gain, from online metrics you can only observe after launch through an A/B test, such as actual watch time or session length, and you would note explicitly that offline and online metrics do not always move together, which is why a staged rollout and an online experiment matter even after offline results look promising.

Finally, on monitoring and feedback, you would mention tracking the distribution of input features over time to catch data drift, tracking the model's prediction distribution and key business metrics after deployment, and being alert to feedback loops, such as the model's own recommendations shaping what users watch and therefore shaping the training data it is retrained on in the future, a form of bias that recommendation systems are particularly prone to. Mentioning this last point specifically tends to stand out, because it shows you are thinking past the first deployment to how the system behaves over months.

Behavioral interviews: the part engineers underestimate

Technical candidates sometimes treat the behavioral round as an afterthought, but for many teams it is where a close technical decision gets settled, because it is the best signal they have about how you will actually work with the people already on the team. The structure that tends to produce clear, convincing answers is the STAR format: Situation, Task, Action, Result. The important part is that you describe a specific, real episode with enough detail that the interviewer can picture it, rather than a generic description of how you usually behave.

Take a common prompt: tell me about a time you disagreed with a colleague about a technical decision. A weak answer stays abstract: "I try to listen to other perspectives and find common ground." A stronger answer is concrete: the situation was that your team had built a model that improved an offline metric but you discovered, while reviewing the evaluation split, that the improvement came from a subtle form of leakage; the task was to raise this before the model shipped, knowing the deadline was close and a colleague who built the model disagreed with your read of the leakage; the action was that you reproduced the issue in a small, isolated example, showed the colleague exactly where the leakage came from, and proposed a corrected validation split together with a short extension to the timeline; the result was that the corrected model was slightly less impressive offline but performed as expected after launch, and the team adopted a stricter validation checklist afterward. This kind of answer does two things at once: it answers the behavioral question honestly, and it incidentally demonstrates technical judgment about leakage, which is exactly the kind of overlap that makes an answer memorable.

Common mistakes that show up again and again

Across all five areas, a small set of mistakes recurs often enough that it is worth naming them plainly.

  • Reciting a definition instead of reasoning through it, for example naming "bias-variance tradeoff" without being able to say what evidence in a specific scenario points to one or the other
  • Reaching for the most advanced technique by default, proposing a deep neural network for a small tabular dataset where a gradient boosted tree would likely perform better and train faster
  • Treating accuracy as the default metric without asking what the costs of different errors actually are
  • Jumping into a system design answer with an architecture diagram before clarifying the goal, scale and latency constraints
  • Ignoring data quality and leakage, as if the only hard part of machine learning is choosing a model
  • Forgetting that a model in production needs monitoring, retraining, and a plan for what happens when the data distribution shifts
  • Giving behavioral answers that are vague or hypothetical rather than specific and real
  • Not asking clarifying questions at all, which an interviewer often reads as a sign you will charge ahead on an ambiguous problem without checking you are solving the right one

How to prepare without wasting time

Given five fairly different areas, it helps to prepare deliberately rather than reading everything you can find. A practical allocation of effort looks roughly like this: spend time reviewing core data structures and practicing a moderate number of coding problems until you are comfortable thinking out loud under mild time pressure, including some that involve arrays, strings and simple numerical computation rather than only classic algorithm puzzles. Spend real time making sure you can explain, from first principles and with a concrete example, the handful of concepts that recur most often: bias and variance, precision and recall, overfitting and regularization, cross-validation, and the assumptions behind whichever models you claim familiarity with on your resume. If your resume says you used logistic regression on a project, you should be able to explain what the model assumes, what its decision boundary looks like, and why you chose it over alternatives, because interviewers will ask about whatever you wrote down.

For case studies and system design, the most effective preparation is usually to have one or two projects, even small ones built from public datasets, that you understand end to end and can discuss honestly, including what went wrong and what you would do differently. A rehearsed, generic answer about recommendation systems is far less convincing than a specific, slightly messy account of a project you actually built, because the second kind invites follow-up questions you can genuinely answer. If you have not built anything like that yet, building one small project before interviewing, something as simple as a classifier on a public tabular dataset taken through the full cycle from a bad baseline to a reasonably validated model, is time well spent, because it gives you real material to draw on in both case study and behavioral rounds.

Finally, practice saying your answers out loud, ideally to another person, even if that person is not an expert in machine learning. The gap between understanding a concept and explaining it clearly under mild pressure is larger than most candidates expect, and the only way to close it is to practice the explaining, not just the understanding.

Summary and what comes next

Machine learning interviews are unpredictable in their exact questions but predictable in their shape. Most loops probe some combination of coding and data manipulation, core ML theory tested through concrete reasoning rather than definitions, applied case studies that reward careful handling of data problems like leakage and imbalance, system design that checks whether you can think past the model to the full production system, and behavioral questions that check how you work with other people. In each area, the strongest answers share a pattern: they ground abstract ideas in specific numbers and specific examples, they state assumptions and ask clarifying questions rather than guessing, and they explain the reasoning behind a choice rather than just naming the choice.

A reasonable next step is to pick one of the five areas where you feel least confident and spend a focused week on it: if that is fundamentals, work through bias-variance and evaluation metrics on a dataset you choose yourself, computing the numbers by hand the way this article did, rather than only reading about them. If that is system design, pick a product you use and sketch the full pipeline from data to serving to monitoring, even without an interviewer in the room, since the practice of narrating a complete design out loud is most of what the real interview tests.