Machine Learning Interview Questions and Answers

In supervised learning every training example comes with the answer you want the model to predict, a label. The model learns the mapping from inputs to that label, for instance predicting whether a parcel will be late from route, weather and weight, using past parcels whose outcome is known.

In unsupervised learning there are no labels. The model looks for structure on its own, such as grouping customers into segments by behaviour or compressing many features into a few. Supervised results can be scored against the known answers; unsupervised results usually need judgement or indirect checks. A third family, reinforcement learning, learns from rewards after taking actions.

What the interviewer is checking: Clear definitions anchored on the presence of labels, with a realistic example.

Likely follow-up: Where does semi-supervised learning fit, and why would you use it?

Both are supervised tasks; the difference is the type of target. Classification predicts a category, such as spam or not spam, or which of five support queues a ticket belongs to. Regression predicts a continuous number, such as the delivery time in minutes or the price of a flat.

The choice affects the loss function and the metrics: classification uses things like log loss, precision and recall, while regression uses errors such as mean absolute error or squared error. Sometimes a problem can be framed either way, for example predicting an exact delay versus predicting whether it exceeds one hour, and the right framing depends on the decision the business actually makes.

What the interviewer is checking: That the candidate links the task type to loss and metrics and can reframe a problem.

Likely follow-up: Is logistic regression a regression or a classification algorithm?

Bias is error from a model being too simple to capture the real pattern, so it underfits: it is wrong in a consistent way. Variance is error from a model being too sensitive to the particular training sample, so it overfits: it changes a lot if the training data changes.

Making a model more flexible, with more features, deeper trees or more parameters, usually lowers bias but raises variance. The aim is the level of complexity where error on unseen data is lowest. More data and regularisation tend to reduce variance, while richer features or a more flexible model reduce bias. A large gap between training and validation scores points to variance; both being poor points to bias.

What the interviewer is checking: That the candidate can connect the idea to symptoms in the training and validation scores.

Likely follow-up: Your model has high bias. What would you try first?

Overfitting is when a model learns the noise and quirks of the training data instead of the general pattern, so it scores very well on training data and noticeably worse on new data. You spot it by comparing training and validation performance, or by watching validation error rise while training error keeps falling.

To reduce it: collect more data, simplify the model, use regularisation, limit tree depth, stop training early, drop noisy features, and use cross-validation to make the validation estimate trustworthy. Ensembles that average many models, such as random forests, also help. I would first confirm there is no data leakage, because that makes a model look better rather than worse.

What the interviewer is checking: Detection via a train-versus-validation gap and a toolbox of remedies, not a single trick.

Likely follow-up: What does early stopping actually monitor?

The training set fits the model's parameters. The validation set is what you use to make choices: which algorithm, which hyperparameters, which features. The test set is touched once, at the end, to estimate how the final model will behave on genuinely unseen data.

If you tune against the test set, you leak information from it into your choices, and the final score becomes optimistic because you effectively selected the model that fit that particular sample. Keeping a clean test set gives an honest estimate. When data is scarce, cross-validation replaces a single validation split, but I still hold out a final test set.

What the interviewer is checking: Understanding that each split has a different role and the test set must stay untouched.

Likely follow-up: You already looked at the test score three times while tuning. What do you do now?

You split the training data into k equal parts. For each part in turn, you train on the other k-1 parts and evaluate on the held-out part, then average the k scores. Every example gets used for validation exactly once, so the estimate is less dependent on one lucky or unlucky split.

It is most useful with small or medium datasets, and for comparing models or tuning hyperparameters. The cost is training k models. Use stratified folds for classification so class proportions stay similar, and use time-ordered splits for time series, because shuffling would let the model peek at the future.

def kfold_indices(n, k):
    fold = n // k
    for i in range(k):
        val = list(range(i * fold, (i + 1) * fold))
        train = [j for j in range(n) if j not in val]
        yield train, val
for train, val in kfold_indices(6, 3):
    print("train", train, "validate", val)

train [2, 3, 4, 5] validate [0, 1]
train [0, 1, 4, 5] validate [2, 3]
train [0, 1, 2, 3] validate [4, 5]

What the interviewer is checking: That the candidate can describe the mechanism and knows where plain k-fold is the wrong choice.

Likely follow-up: Why would a shuffled k-fold give misleading results on sales data over time?

If only about 1% of transactions are fraud, a model that always predicts "not fraud" is 99% accurate and catches nothing. Accuracy counts all correct predictions equally, so on imbalanced data the majority class dominates it.

I would ask for the confusion matrix and look at recall for the fraud class, which is the share of real fraud caught, along with precision, which is the share of alerts that were truly fraud. The right balance depends on cost: missed fraud versus the effort of reviewing false alarms. A useful sanity check is always to compare against a trivial baseline.

# 990 genuine, 10 fraud; a "model" that always says genuine
y_true = [0] * 990 + [1] * 10
y_pred = [0] * 1000
tp = sum(t == 1 and p == 1 for t, p in zip(y_true, y_pred))
fn = sum(t == 1 and p == 0 for t, p in zip(y_true, y_pred))
acc = sum(t == p for t, p in zip(y_true, y_pred)) / len(y_true)
recall = tp / (tp + fn)
print("accuracy", acc, "recall", recall)

accuracy 0.99 recall 0.0

What the interviewer is checking: Awareness that accuracy misleads under class imbalance and which metrics to ask for instead.

Likely follow-up: Which would you prioritise for fraud, precision or recall, and who decides?

Precision is the fraction of predicted positives that are really positive: true positives over true positives plus false positives. Recall is the fraction of actual positives that you found: true positives over true positives plus false negatives. F1 is their harmonic mean, which stays low unless both are reasonably high.

Favour recall when missing a case is expensive, such as screening for a serious illness or a security alert. Favour precision when false alarms are expensive, such as auto-blocking a customer's account. F1 is convenient for one number, but it hides which side you are weak on, so report both.

def prf(y_true, y_pred):
    tp = sum(t == 1 and p == 1 for t, p in zip(y_true, y_pred))
    fp = sum(t == 0 and p == 1 for t, p in zip(y_true, y_pred))
    fn = sum(t == 1 and p == 0 for t, p in zip(y_true, y_pred))
    precision = tp / (tp + fp) if tp + fp else 0.0
    recall = tp / (tp + fn) if tp + fn else 0.0
    f1 = 2 * precision * recall / (precision + recall) if precision + recall else 0.0
    return round(precision, 3), round(recall, 3), round(f1, 3)
y_true  = [1, 1, 1, 1, 0, 0, 0, 0, 0, 0]
y_pred  = [1, 1, 0, 0, 1, 0, 0, 0, 0, 0]
print(prf(y_true, y_pred))

(0.667, 0.5, 0.571)

What the interviewer is checking: Correct formulas and the judgement to choose a metric from the cost of each error type.

Likely follow-up: How does moving the classification threshold change precision and recall?

Data leakage is when information that would not be available at prediction time influences training, so offline scores look better than reality. Classic cases: a feature that is really the outcome in disguise, such as a "refund issued" flag when predicting complaints, and preprocessing fitted on all the data before splitting.

The second case is subtle. If you compute a mean, a scaling range or an imputation value over the full dataset, the test rows have influenced the transformation. The fix is to split first, fit every transformation on the training part only, then apply it to validation and test, ideally inside a single pipeline. Also watch for duplicates across splits and for time leakage.

import statistics as st
data = [10, 12, 11, 13, 14, 12, 90]       # the last row is the test set's outlier
train, test = data[:5], data[5:]
leaky_mean = st.mean(data)                # statistic computed over everything
safe_mean = st.mean(train)                # statistic computed on training rows only
print(round(leaky_mean, 2), safe_mean)

23.14 12

What the interviewer is checking: Recognition of both obvious and subtle leakage and the discipline of fitting only on training data.

Likely follow-up: Your validation score is suspiciously near perfect. What do you check first?

The ROC curve plots the true positive rate against the false positive rate across all possible thresholds. AUC is the area under it, and has a handy interpretation: the probability that the model scores a randomly chosen positive example higher than a randomly chosen negative one. 0.5 is chance level and 1.0 is perfect ranking.

It measures ranking quality independent of any threshold, which is useful, but it can look flattering on heavily imbalanced data because the large number of negatives keeps the false positive rate low. In that case precision-recall curves are more informative. AUC also says nothing about calibration or about the threshold you will actually deploy.

def roc_auc(y_true, scores):
    pos = [s for t, s in zip(y_true, scores) if t == 1]
    neg = [s for t, s in zip(y_true, scores) if t == 0]
    wins = 0.0
    for p in pos:
        for n in neg:
            wins += 1.0 if p > n else 0.5 if p == n else 0.0
    return wins / (len(pos) * len(neg))
y = [1, 1, 0, 1, 0, 0]
s = [0.9, 0.8, 0.7, 0.6, 0.3, 0.2]
print(roc_auc(y, s))

0.8888888888888888

What the interviewer is checking: Understanding AUC as a ranking probability and awareness of its limits on imbalanced data.

Likely follow-up: How would you pick an operating threshold once you have a good AUC?

First, pick metrics that suit it, such as precision, recall and precision-recall curves, and make sure the validation split keeps the same ratio. Then options at different levels: use class weights so the rare class costs more in the loss; resample, by oversampling the minority or undersampling the majority; or generate synthetic minority examples. Collecting more minority data is often the best fix.

Resample only the training set, never the validation or test data, or the estimate will be misleading. Finally, the decision threshold is a lever of its own: after training, choose it from the cost of each error rather than defaulting to 0.5. Resampling can distort predicted probabilities, so recalibrate if you need real probabilities.

What the interviewer is checking: A structured set of options plus the traps: resample only training data and tune the threshold.

Likely follow-up: What can go wrong with oversampling before you split the data?

Regularisation adds a penalty on the size of the model's weights to the loss, discouraging it from fitting noise. You trade a small increase in bias for a bigger reduction in variance. The strength is a hyperparameter, usually chosen with cross-validation.

L2 penalises the sum of squared weights and shrinks them smoothly toward zero without usually reaching it; it handles correlated features gracefully. L1 penalises the sum of absolute weights and tends to push some weights exactly to zero, which acts as feature selection and gives sparse models. Features should be on a comparable scale first, otherwise the penalty treats them unfairly.

# L2 penalty shrinks a weight: closed form for one feature, no intercept
xs = [1, 2, 3, 4]
ys = [2.1, 3.9, 6.2, 7.8]
sxy = sum(x * y for x, y in zip(xs, ys))
sxx = sum(x * x for x in xs)
for lam in (0, 5, 50):
    print(lam, round(sxy / (sxx + lam), 3))

0 1.99
5 1.706
50 0.746

What the interviewer is checking: That the candidate can explain the penalty, the L1 sparsity effect and the need for scaling.

Likely follow-up: How would you choose the regularisation strength?

Models that rely on distances or on gradient-based optimisation are sensitive to scale. k-nearest neighbours and k-means compare distances, so a feature measured in thousands would drown out one measured in fractions. Linear and logistic regression, neural networks and regularised models converge better and penalise fairly when features share a similar range.

Tree-based models such as decision trees, random forests and boosted trees only ask whether a value is above a threshold, so monotonic rescaling does not change the splits. Common choices are standardisation (zero mean, unit variance) and min-max scaling. Fit the scaler on training data only, and apply the same parameters at prediction time.

What the interviewer is checking: Knowing why scaling matters, which algorithm families are affected, and the fit-on-train rule.

Likely follow-up: Does scaling matter for a decision tree, and what about for a single linear regression with no penalty?

For a few unordered categories I use one-hot encoding, one binary column per value. For genuinely ordered ones, like small, medium and large, an integer code is acceptable. Giving unordered categories arbitrary integers is a mistake for linear and distance-based models, because it invents an order.

With thousands of values, one-hot creates a huge sparse matrix. Alternatives are grouping rare values into an "other" bucket, hashing, learned embeddings, or target encoding, which replaces a category with a statistic of the target. Target encoding leaks easily, so compute it inside cross-validation folds, with smoothing. Always plan for categories that appear at prediction time but were never seen in training.

What the interviewer is checking: Practical encoding choices, the high-cardinality problem and the leakage risk in target encoding.

Likely follow-up: How does your pipeline behave when an unseen category arrives in production?

Gradient descent minimises a loss by repeatedly measuring how the loss changes with each parameter, the gradient, and nudging each parameter a small step in the direction that reduces the loss. The learning rate is the step size.

Too large and the steps overshoot the minimum, so the loss oscillates or even grows. Too small and training is painfully slow or stalls in flat regions. In practice we use mini-batches for efficiency, scale the features so the surface is well behaved, and often decay or adapt the rate during training. For non-convex models, it may settle in a local minimum or a plateau rather than the global best.

# fit y = w*x + b by gradient descent on mean squared error
xs = [1, 2, 3, 4, 5]
ys = [3, 5, 7, 9, 11]   # exactly y = 2x + 1
w = b = 0.0
lr = 0.02
for step in range(2000):
    dw = sum(2 * ((w * x + b) - y) * x for x, y in zip(xs, ys)) / len(xs)
    db = sum(2 * ((w * x + b) - y) for x, y in zip(xs, ys)) / len(xs)
    w -= lr * dw
    b -= lr * db
print(round(w, 3), round(b, 3))

2.0 1.0

What the interviewer is checking: A clear mechanism plus the effect of step size and practical mitigations.

Likely follow-up: How does stochastic or mini-batch gradient descent differ from using the whole dataset?

Linear regression predicts a number as a weighted sum of the features and is usually fitted by minimising squared error. Logistic regression takes the same weighted sum but passes it through the sigmoid function, which squashes it into a value between 0 and 1 that is read as the probability of the positive class. It is trained by minimising log loss.

The output is a probability, so you still choose a threshold to turn it into a class. The default of 0.5 is just a default; the right threshold depends on error costs. The decision boundary is linear in the features, which makes the model fast and interpretable, but it cannot capture complex interactions unless you add features.

import math
def sigmoid(z):
    return 1 / (1 + math.exp(-z))
z = 0.4
p = sigmoid(z)
print(round(p, 3), p >= 0.5, p >= 0.7)

0.599 True False

What the interviewer is checking: Understanding of the sigmoid, log loss and the separation between probability and decision threshold.

Likely follow-up: How do you interpret a coefficient in a logistic regression?

First understand why they are missing, because the reason matters: a blank might mean not applicable, not collected, or a data error. Then choose a strategy. Drop rows or columns only if few are affected and the loss is random. Otherwise impute: median for skewed numeric data, most frequent or an explicit "unknown" for categories. Some tree implementations handle missing values natively.

Often the fact that a value is missing is itself informative, so I add an indicator column. All imputation values must be computed on training data only and reused at prediction time. Keep in mind that mean imputation shrinks the variance of the feature.

rows = [{"age": 31, "city": "Pune"}, {"age": None, "city": "Nashik"}, {"age": 45, "city": None}, {"age": 27, "city": "Pune"}]
ages = sorted(r["age"] for r in rows if r["age"] is not None)
median = ages[len(ages) // 2]
for r in rows:
    r["age_missing"] = r["age"] is None
    if r["age"] is None:
        r["age"] = median
    if r["city"] is None:
        r["city"] = "unknown"
print(rows[1], rows[2])

{'age': 31, 'city': 'Nashik', 'age_missing': True} {'age': 45, 'city': 'unknown', 'age_missing': False}

What the interviewer is checking: That the candidate asks why data is missing, picks a method by case and avoids leakage.

Likely follow-up: When is dropping rows with missing values actually harmful?

A decision tree repeatedly splits the data on the feature and threshold that best separates the target, using a criterion such as Gini impurity or information gain, until a stopping rule is met. It is easy to explain, but an unconstrained tree memorises the training data and has high variance: small changes in data can produce a very different tree.

A random forest trains many trees, each on a bootstrap sample of the rows and considering only a random subset of features at each split, then averages their predictions or takes a vote. The trees make different mistakes, so averaging cancels much of the variance while bias stays similar. You give up some interpretability, but gain accuracy and robustness with little tuning.

What the interviewer is checking: Understanding of splitting, why single trees overfit, and why bagging with random features helps.

Likely follow-up: What is out-of-bag error and why is it useful?

A random forest builds trees independently and averages them, which mainly reduces variance. Gradient boosting builds trees sequentially: each new, usually shallow, tree is fitted to the errors the current ensemble still makes, and is added with a small learning rate. This mainly reduces bias and often reaches higher accuracy on tabular data.

The price is more tuning: learning rate, number of trees and tree depth interact, and too many rounds will overfit unless you use early stopping on a validation set. Forests are a strong, forgiving first model and train in parallel. I reach for boosting when I need the last bit of accuracy and have time to tune and validate it carefully.

What the interviewer is checking: Parallel-averaging versus sequential error-correcting ensembles and the tuning implications.

Likely follow-up: Which hyperparameters would you tune first for boosting, and how would you stop it overfitting?

k-means picks k starting centres, assigns every point to its nearest centre, recomputes each centre as the mean of its points, and repeats until assignments stop changing. It minimises the within-cluster sum of squared distances.

Limitations: you must choose k in advance; the result depends on initial centres and can land in a poor local optimum, so run it several times or use a smarter initialisation; it assumes roughly round, similar-sized clusters; it is sensitive to outliers and to feature scale; and it only works with meaningful numeric distances. The example shows two different starts reaching different final error.

def kmeans_1d(points, centers, iters=10):
    for _ in range(iters):
        groups = [[] for _ in centers]
        for p in points:
            nearest = min(range(len(centers)), key=lambda i: abs(p - centers[i]))
            groups[nearest].append(p)
        centers = [sum(g) / len(g) if g else c for g, c in zip(groups, centers)]
    sse = sum(min((p - c) ** 2 for c in centers) for p in points)
    return [round(c, 1) for c in centers], round(sse, 1)
pts = [0, 1, 10, 11, 20, 21]
print(kmeans_1d(pts, [0, 1]))
print(kmeans_1d(pts, [0, 20]))

([0.5, 15.5], 101.5)
([3.7, 17.3], 121.3)

What the interviewer is checking: Knowing the algorithm, its assumptions and its sensitivity to initialisation and scale.

Likely follow-up: How would you choose k when you have no labels?

I combine internal measures with usefulness. Internal measures look at the geometry: how tight clusters are and how well separated they are, for example with a silhouette score, or the elbow in the within-cluster error as k grows. These guide the choice of k but are not a verdict.

I also test stability: do similar clusters appear with different seeds or on resampled data? Then I inspect the clusters directly, profiling what distinguishes each one, and ask whether the segments are meaningful and actionable for the business. If the clusters feed a downstream task, I judge them by how that task improves. A tidy score on clusters nobody can use is not success.

What the interviewer is checking: Honest handling of unsupervised evaluation: internal metrics, stability and downstream value.

Split by time: train on earlier periods and validate on later ones. Shuffling mixes future rows into training, so the model effectively sees what it is meant to predict, and the score is too optimistic. Rolling or expanding-window validation repeats this: train up to week t, test on the next block, move forward, and average.

Also check features. Anything built from the future, like a rolling average that includes the target period, is leakage. Leave a gap between train and test if features use lagged windows. Test conditions should resemble deployment, including the forecast horizon, and seasonal patterns need enough history in each fold.

What the interviewer is checking: Time-aware validation and attention to leakage through features.

Likely follow-up: How do you compare the model with a simple seasonal baseline?

Training-serving skew is when the features the model sees in production differ from those it was trained on, even though the code looks the same. Typical causes: preprocessing implemented twice, once in a notebook and once in the service; different handling of missing values or unseen categories; stale or late-arriving data; and different time windows.

To avoid it, package preprocessing and model together as one versioned artefact, so the same code runs in both places, or serve features from a shared feature store. Log the actual features used at prediction time, compare their distributions with training, and add tests with fixed example inputs and expected outputs. Roll out gradually, shadowing the old system first, before switching traffic.

What the interviewer is checking: Practical MLOps thinking: single preprocessing path, logging, and staged rollout.

Likely follow-up: How would you run a new model in shadow mode?

There are two kinds. Data drift means the input distribution has shifted from training; concept drift means the relationship between inputs and the target has changed. I monitor input feature distributions with a statistic such as the population stability index or a distribution test, the prediction score distribution, data quality (nulls, ranges), and, once labels arrive, the real performance metrics, which may lag.

Alerts compare against the training baseline with thresholds tuned to avoid noise. On detection I investigate first: it may be an upstream pipeline bug, not a real change. If it is real, retrain on recent data, validate against the incumbent, and redeploy. Retraining on a schedule or on triggers should itself be tested.

import math
def psi(expected, actual):
    # expected/actual: bin proportions that each sum to 1
    return sum((a - e) * math.log(a / e) for e, a in zip(expected, actual))
train_bins = [0.25, 0.25, 0.25, 0.25]
live_same  = [0.24, 0.26, 0.25, 0.25]
live_shift = [0.05, 0.15, 0.30, 0.50]
print(round(psi(train_bins, live_same), 4))
print(round(psi(train_bins, live_shift), 4))

0.0008
0.5554

What the interviewer is checking: Distinguishing data and concept drift, monitoring without labels, and a sensible response plan.

Likely follow-up: Labels arrive six weeks late. How do you know the model is degrading before then?

I work through likely causes in order. First, was the offline score trustworthy: any leakage, a split that did not match how data arrives, or tuning against the test set? Second, is the production data the same as the training data: training-serving skew, drift, a pipeline bug, or a population the model never saw?

Third, is the metric the right one: offline accuracy may not reflect the business outcome, and the model may change user behaviour, creating feedback effects. I compare logged production features with training data, slice errors by segment, and replay production inputs offline. If the cause is unclear, I run an A/B test against the previous solution to measure real impact.

What the interviewer is checking: A systematic debugging path across validation, data, metric choice and feedback effects.

Likely follow-up: How would you tell whether a drop is from drift or from a broken feature pipeline?

I would quantify the trade-off rather than argue in the abstract. Build a simple, transparent baseline, such as regularised logistic regression or a shallow tree, and a stronger model, then compare them on the metrics that matter. Often the gap is small and the simple model wins on maintainability and trust.

If the complex model is clearly better, I look at explanation tools such as feature importance and per-prediction attributions, and I am honest that these approximate the model's behaviour rather than reveal it. Where decisions affect people materially, the requirement may mean using an inherently interpretable model, whatever the accuracy. Check fairness across groups, and document the choice with the reasoning.

What the interviewer is checking: Judgement on the accuracy-interpretability trade-off and honesty about the limits of explanation tools.

Likely follow-up: What is the difference between global and local explanations?