Machine Learning Interview Questions

Simpler models like logistic regression are more interpretable (a) and are cheaper to train and deploy (c). Option (b) is incorrect because underfitting is not primarily a data-quantity issue — simpler models may underfit because their hypothesis class is too restricted, not because they lack data. Option (d) is incorrect because simpler models do not always outperform complex models; the best choice depends on the data and problem complexity.

The list X = [0, 10, 20] is given explicitly in the code. min_val = min(X) evaluates to 0, and max_val = max(X) evaluates to 20. Each element is then transformed by (x - min_val) / (max_val - min_val): (0 - 0) / (20 - 0) = 0.0, (10 - 0) / (20 - 0) = 0.5, (20 - 0) / (20 - 0) = 1.0. The resulting list is [0.0, 0.5, 1.0], which Python prints as [0.0, 0.5, 1.0].

The mapping is built deterministically by enumerate: {'cat': 0, 'dog': 1, 'fish': 2}. Each data item produces a 3-element vector with a 1 at the mapped index. 'dog' → [0,1,0], 'cat' → [1,0,0], 'fish' → [0,0,1], 'dog' → [0,1,0]. The printed output is [[0, 1, 0], [1, 0, 0], [0, 0, 1], [0, 1, 0]].

Hyperparameter tuning and model selection are performed against the validation set so that the test set remains untouched for an unbiased final performance estimate.

The test set is kept unseen until the very end; using it repeatedly risks overfitting to it and would inflate the reported generalization performance.

High bias means the model's assumptions (here, linearity) are too simplistic to capture the real relationship in the data, so it performs poorly even on data it has already seen — that's underfitting, and it shows up as high error on both train and test that are close in magnitude. High variance (overfitting) looks the opposite: low training error but much higher test error, because the model fit noise specific to the training set that doesn't generalize. Similar train/test error alone doesn't mean 'calibrated' — if both are similarly high, that's still a problem, just a different one (bias, not variance) than similar-and-low error would indicate. Data leakage typically shows up as suspiciously good test performance, the opposite of this scenario.

F1 = 2 × (precision × recall) / (precision + recall) — the harmonic mean, which (unlike an arithmetic mean) penalizes a large imbalance between the two: a model with precision 1.0 and recall 0.0 gets an arithmetic mean of 0.5 but an F1 of 0, correctly reflecting that it's useless. It's the right single-number summary when you don't have a strong reason to weight false positives differently from false negatives; when you do (like the disease-screening case, where recall matters far more), reporting F1 alone hides that asymmetry and you should report precision and recall separately, or use a weighted variant like F-beta. F1 is a classification metric with no direct regression analogue.

True. Bias measures the error introduced by a model's simplifying assumptions being too far from the true relationship — a high-bias model is too simple to capture the pattern in the data, so it performs poorly even on the training set it was fit to. That's the definition of underfitting. This is the opposite failure mode from high variance (overfitting), where the model is complex enough to fit training data very closely but fails to generalize to new data.

The order matters because each set has exactly one job: the split must happen before any fitting so no set's information leaks into another; the training set is what parameters are learned from; the validation set is what model/hyperparameter decisions are made against, since using it for those decisions repeatedly (unlike training) is expected and intended; and the test set is touched exactly once, at the very end, specifically because repeatedly checking it and adjusting the model in response would turn it into a second validation set in disguise — an optimistic, no-longer-trustworthy estimate of how the model performs on genuinely unseen data. Reversing steps (e.g., peeking at test performance during tuning) is a common, subtle way real-world offline metrics end up overstating what the model will actually do in production.

Target (or data) leakage occurs when information from outside the training set — most commonly the test set — influences the training process. When preprocessing with a scaler, fitting on the full dataset means the computed mean and standard deviation include test-set values, giving the model indirect knowledge of the test distribution. The fix is to fit the transformer on the training split only and then apply (transform) it to both splits using those learned parameters. In a pipeline, this is typically handled by fitting the entire pipeline on training data only.

When a model has high error on both training and validation sets, it is typically underfitting — it lacks the capacity to capture the underlying pattern, which corresponds to high bias (option a is correct). Switching to a more flexible model can reduce this bias and lower training error, but if the model becomes too complex it may memorize noise, leading to overfitting: training error drops while validation error can rise due to high variance (option c is correct). Option b is wrong because increased flexibility does not guarantee lower validation error — it can worsen it through overfitting. Option d is wrong because high error on both training and validation sets indicates high bias (underfitting), not high variance; high variance would manifest as low training error but high validation error.

Recall directly measures the fraction of true positive cases the model successfully identifies — maximizing it minimizes false negatives, which is exactly the error that's catastrophic here (a missed disease case with no follow-up). Precision instead measures how trustworthy a positive prediction is, which matters more when a false positive is the costly error (e.g., an expensive irreversible action taken on a false alarm) — the opposite priority from this scenario, where a false positive just triggers a cheap follow-up test. Accuracy is a poor fit for rare-disease screening because the disease is rare: a model that predicts 'negative' for everyone can still score high accuracy while catching zero true cases. Precision and recall usually trade off against each other as the classification threshold moves, not move together — raising recall (lowering the threshold to catch more positives) typically lowers precision (more false positives slip through).

Regularization (a), more data (b), reduced complexity (c), and cross-validation with early stopping (e) are all standard, legitimate levers against overfitting: they either constrain the model's capacity to memorize noise, give it less noise-to-signal ratio to overfit to, or stop training at the point generalization starts to degrade. Option d isn't a fix at all — it's discarding the diagnostic signal that revealed the problem in the first place; a model that's never evaluated on held-out data can be badly overfit without anyone finding out until it fails in production.

True. Accuracy just measures the fraction of all predictions that are correct, and on heavily imbalanced data, predicting the majority class every time trivially hits an accuracy equal to the majority class's share of the data — 99% here — while catching zero instances of the minority class (0% recall on it). This is exactly why accuracy alone is a misleading metric on imbalanced datasets, and why metrics like precision, recall, F1, or AUC-ROC (which account for how the model performs on the minority class specifically) are preferred for that scenario.

This tests whether the definitions are actually understood, not memorized as formulas: precision is about trustworthiness of a positive prediction, recall is about coverage of the real positives, and they trade off as the classification threshold moves. A strong answer explains the threshold mechanism specifically (why lowering it raises recall and lowers precision), since that's the part that shows genuine understanding rather than recalled definitions, and connects the choice of operating point to which error type is costlier for the actual problem.

The concept is straightforward, but a strong answer grounds it in a concrete before/after example rather than staying abstract — showing a raw field that's hard for a model to use directly, and a derived version that exposes the actual signal. The point about feature engineering often mattering more than algorithm choice (especially for tabular/non-deep-learning problems) is the workplace-relevant takeaway that separates someone who's applied this from someone reciting a definition.

AUC-ROC's threshold-independence is what makes it useful for comparing models before you've committed to an operating point, and its probabilistic interpretation — the probability a randomly chosen positive example is ranked above a randomly chosen negative one — is a common interview follow-up.

This question tests whether the candidate can identify group-level data leakage, design a group-aware split, reason about temporal ordering, and account for class imbalance — all core data-preparation skills at the mid-level.

This question tests whether the candidate can design a domain-aware split that simulates real deployment to an unseen location, handle class imbalance correctly across splits, and critically evaluate the reliability of the resulting generalization estimate.

StandardScaler.fit_transform on line 2 computes the mean and standard deviation used for scaling from the entire dataset X — before the train/test split even happens. That means the test set's own statistics influenced the scaling parameters applied to the training data, a subtle form of data leakage: the model is trained with information (aggregate statistics of the test set) that wouldn't be available at real prediction time. It inflates test performance because the test set is no longer a genuinely unseen distribution to the pipeline. The fix is to fit the scaler only on the training set (scaler.fit(X_train)), then use that already-fit scaler to .transform() (not re-fit) the test set — so the test set's statistics never influence anything learned from or applied to the training data. This exact bug (fitting any preprocessing step before splitting) is one of the most common real-world sources of an offline metric that doesn't hold up in production.

days_since_cancellation_request is populated specifically because a customer already initiated a cancellation — it's a near-direct proxy for (or downstream consequence of) the churn label itself, not information that exists at the point in time a real, forward-looking prediction would need to be made. This is target leakage: a feature that's only available because the outcome already happened (or is derived from data generated after the event you're trying to predict). Offline, the model looks excellent because this one feature is almost as good as the label; in production, making a genuinely forward-looking prediction about a customer who hasn't yet requested cancellation, that feature is absent or meaningless, and the model's real skill collapses to near-random. The fix is to audit every feature for whether it could plausibly be known at the actual moment of prediction, and drop anything (like this one) that's really just a restatement of the outcome.

The L1 penalty's diamond-shaped constraint region has corners on the axes, so the optimal solution frequently lands exactly on an axis where some coefficients are zero. The L2 penalty's circular constraint region is smooth and tangent to the loss contour almost everywhere except on axes, so coefficients are shrunk but not zeroed. This geometric difference is why L1 induces sparsity and L2 does not.

Option (b) is correct. On line 10, imputer.fit_transform(features) computes column means from the entire dataset — including rows that will later become the test set — and uses those means to fill missing values. This leaks test-set distributional information into the training features. The correct approach is to split first, then call imputer.fit_transform(X_train) on the training data and imputer.transform(X_test) on the test data. Option (a) is wrong because dropping the target column from features is correct practice. Option (c) is wrong because a fixed random_state ensures reproducibility, not bias. Option (d) is wrong because mean imputation is a valid strategy; the issue is leakage, not the choice of statistic.

AIC's penalty 2k is constant in n, so it targets predictive optimality (efficiency) regardless of whether the true model is in the candidate set. BIC's penalty k·log(n) grows with n, which makes it increasingly favor the simplest model that adequately fits, yielding consistency (selecting the true model with probability → 1) under the assumption that the true model is among the candidates. The log(n) term is the key driver of the difference.

The chronological split (c) must come first: without it, any downstream step could train on or tune against future data, introducing look-ahead bias. Cross-validation (d) strictly follows because it must operate only on the training period — and rolling-origin CV itself enforces temporal ordering within training, preventing leakage from future folds into past folds. Retraining (a) strictly follows CV because it uses the hyperparameters selected during tuning; retraining before tuning would mean the selected hyperparameters are irrelevant to the deployed model. Final scoring on the test set (b) strictly follows retraining because you need the finished model before you can evaluate it, and touching the test set earlier (e.g., for model selection or tuning) leaks test information into the training process. Each adjacent pair has a hard dependency: c→d (must split before tuning on training-only data), d→a (must select hyperparameters before final training), a→b (must have a trained model before scoring).