AI Engineer Interview Daily — 2026-09-21: ML Fundamentals

🌏 中文版

Today's Topic

Monday's rotation is ML Fundamentals — the foundation every AI Engineer interview rests on. Whatever comes later, LLMs or agents, interviewers almost always start here to check whether you have a solid intuition for why models go wrong. Today's practice question is an end-to-end project design question, because it forces you to thread bias-variance, regularization, validation strategy, and evaluation metrics — usually memorized as separate flashcards — into one decision framework you can actually walk through on a whiteboard. That's exactly the skill tested from phone screens through onsite rounds.

Core Concepts Cheat Sheet

Diagnose bias-variance with learning curves, not definitions

Interviewers don't want to hear "high bias means underfitting, high variance means overfitting" recited back — they want to see how you'd diagnose it. High training error and high validation error usually point to high bias: add signal, move to a more expressive model, or loosen regularization. Low training error but a validation error that's noticeably higher points to high variance: add regularization, add data, or move to a simpler model family. Framing it as "I'd plot the learning curves first and look at the gap between the two lines before deciding which direction to adjust" reads as a more senior answer than reciting the textbook split.

L1 and L2 regularization both add a penalty to the loss function, but they penalize different things

Both exist to stop a model from memorizing training-set noise at the expense of generalization, and both work by adding a penalty term to the loss function. L1 (Lasso) adds the sum of the absolute values of the coefficients, which pushes unimportant features' coefficients all the way to zero — effectively performing feature selection as a side effect. L2 (Ridge) adds the sum of the squared coefficients, shrinking all coefficients toward zero without ever zeroing them out, which suits situations where features are highly correlated. A common follow-up is "when would you pick L1 over L2" — the answer hinges on whether you need a sparse solution: pick L1 when you want interpretability or automatic feature selection, pick L2 when you just want a more stable model and don't care about sparsity.

The batch-size choice in gradient descent trades compute cost against convergence stability

Batch gradient descent computes the gradient over the entire dataset — accurate direction, but each step is expensive. Stochastic gradient descent (SGD) uses one sample or a small batch at a time — noisier, but updates faster and escapes local minima more easily. Mini-batch sits between the two and is the practical default. When asked "why not just always use batch gradient descent," the key point is that at scale, batch gradient descent has to sweep the entire dataset on every step, which computation and memory can't sustain — and the "noise that helps escape local minima" property of SGD is an advantage, not a drawback, on the non-convex loss surfaces typical of deep learning.

On imbalanced data, accuracy is the metric most likely to lie to you

When the positive class is only 1% of the data, a model that always predicts negative still scores 99% accuracy — and is completely useless. Interviewers want to hear that you'd switch metrics based on business risk: precision measures "of everything I called positive, how much actually was," recall measures "of everything that's actually positive, how much did I catch" — the two trade off against each other, and F1 is their harmonic mean. If the business cares more about ranking than an absolute threshold, ROC-AUC — or PR-AUC, which is more honest on imbalanced data — is the better call. Being able to say "which metric to use depends on whether missing a positive or misclassifying a negative costs more" is what signals engineering judgment.

Cross-validation's leakage trap: every look at the validation score leaks a little information

Cross-validation exists to make model evaluation more robust, but the trap interviewers love to probe is this: if you repeatedly use the validation score to tune hyperparameters, pick features, or select a model, you're quietly leaking validation-set information into the model-selection process, and the validation score becomes systematically optimistic. The correct approach is to keep a held-out test set that's never touched until the very end, used exactly once; cross-validation's job is limited to model selection and hyperparameter search. Saying "the validation score isn't free — every use of it spends some of its credibility" lands better than just "I do cross-validation."

Today's Practice Question

The Question

You're interviewing for a Data Scientist role, and the interviewer says: "Walk me through how you'd approach an end-to-end machine learning project on large-scale data — what choices would you make around feature engineering, model selection, and validation strategy, and why?"

Source: Adapted from PracHub's interview question bank (Transunion, Data Scientist, Medium)　Difficulty: Intermediate　Round: onsite / technical deep-dive

How to Break It Down

1. Clarify first: Ask whether "large-scale" means row count or feature count, whether the target is classification or regression, whether the data has a temporal structure, and which kind of error (false positive vs. false negative) the business is more sensitive to. These answers determine every choice that follows.
2. Build a framework: Break the project into four stages — feature engineering (must avoid leakage), model family selection (tied to the bias-variance sweet spot), validation strategy design (must mirror the production data distribution), and evaluation metric choice (must map to business risk). The four stages are interdependent, not separate technology picks.
3. Go deep on the core: On feature engineering, stress that every statistic (mean, standard deviation, encoding maps) must be fit only on the training fold and then applied to the validation fold — otherwise the validation score comes out inflated. On model selection, explain that large-scale structured data usually starts with gradient boosting as a strong baseline — faster to iterate on and more interpretable than deep learning — and only moves to more complex architectures once the data volume is large enough and the features have sequential or unstructured character. On validation strategy, temporal data needs a time-based split, never a random one, or you end up predicting the past from the future. On metrics, tie the choice back to the error-cost asymmetry established during clarification.
4. Close strong: Bring the whole flow back to "this set of choices isn't one-and-done — after launch, keep tracking whether the training/validation gap widens over time (a sign of concept drift), and periodically re-audit the feature pipeline for leakage risk and the model's calibration." This shows you're thinking about the full production lifecycle, not just chasing a one-time offline score.

Sample Answer (What You'd Actually Say)

Pin down the data and business constraints first: I'd start by confirming whether "large-scale" means a high feature count or a high row count, whether the target class is imbalanced, whether the data has a temporal structure, and whether the business cares more about missing a positive or misclassifying a negative. Those answers drive every trade-off I make from here — I'm not picking the model before understanding what I'm optimizing for.

Feature engineering and model selection: On features, I'd strictly fit every statistic on the training fold and apply it to the validation fold, to rule out leakage. On the model, for large-scale structured data I'd start with gradient boosting — something like LightGBM — as a strong baseline, because it trains fast, stays interpretable, and is insensitive to feature scale, letting me quickly see where the bias-variance balance actually sits before deciding whether to move to something more complex. I wouldn't reach for deep learning on day one and add unnecessary complexity and debugging cost.

Validation strategy and monitoring: If the data has a temporal structure, I'd use a time-based split instead of random k-fold, to avoid the trap where predicting the past from the future looks great offline and collapses in production. For the metric, I'd pick F1 or PR-AUC based on the error costs we established earlier, rather than defaulting to accuracy. After launch, I'd keep tracking whether the gap between training and validation performance widens over time — usually an early signal of concept drift — alongside periodic re-checks of the feature pipeline for any newly introduced leakage.

Self-Check List

Use this table to check whether your answer covered the key points:

Further Reading

• Machine Learning Interview Questions — PracHub — Source of today's practice question; a bank of real interview questions from companies including Uber, OpenAI, Google, and Transunion, with difficulty ratings.
• Feature Engineering Interview Questions – Top 30 with Answers (2026) — An extension of the feature-engineering section, covering filter/wrapper/embedded feature selection and concrete leakage cases.
• 25 Machine Learning Interview Questions for 2026 (And How Senior Candidates Actually Answer Them) — A mind-map of the full ML interview landscape, with sample senior-candidate answers worth comparing against today's sample answer section.

References

• Machine Learning Interview Questions — PracHub — Source of today's practice question, "Transunion Data Scientist end-to-end ML project design."
• 25 Machine Learning Interview Questions for 2026 — InterviewPal — Source for the "diagnose bias-variance with learning curves" concept section.
• Understanding L1 and L2 regularization — Weights & Biases — Source for the "L1 and L2 regularization" concept section.
• GitHub - andrewekhalel/MLQuestions — Source for the "batch-size trade-off in gradient descent" and "cross-validation's leakage trap" concept sections.
• Most Asked Data Science Interview Questions and Answers — Source for the "accuracy lies on imbalanced data" concept section.