TL;DR: Bias is error from a model too simple; variance is error from a model that memorized noise. The diagnostic is the train-vs-validation gap, and on small customer pilots the killer is almost always variance, so start with a simpler, higher-bias model and let validation curves, not the demo, tell you when to add capacity.
How to approach it
Give the one-line decomposition, then immediately make it diagnosable: "Bias is error from a model too simple to capture the pattern; variance is error from a model so flexible it memorizes noise. I can tell which one I have by comparing training error to validation error."
A strong answer
Anchor it in numbers. You're building a demand forecaster for a retail customer:
- Linear regression: 18% training error, 19% validation error. Errors are close but both high → high bias (underfitting). The model can't represent seasonality or promotions. More data won't help; more capacity or better features will.
- Unconstrained gradient-boosted trees: 2% training error, 21% validation error. Big gap → high variance (overfitting). It memorized last year's noise. More capacity makes it worse; regularization, simpler model, or more data helps.
The whole diagnosis collapses to one decision tree you can run on any training run:
The tradeoff is cheap to reproduce for yourself, and having actually run it changes how confidently you talk about it. Fit polynomials of increasing degree to 40 noisy samples of a sine curve and score against 200 held-out points (we ran exactly this; RMSE below):
| Model | Train RMSE | Validation RMSE | Diagnosis |
|---|---|---|---|
| Degree 1 (a line) | 0.56 | 0.51 | Both high, close together: bias |
| Degree 3 | 0.30 | 0.29 | Both low, close: healthy |
| Degree 15 | 0.24 | 0.44 | Best training score in the table, worst validation: variance |
The degree-15 row is the pilot demo in miniature: it has the most impressive number on the data it saw and it is the worst model on the data it did not, because it spent its extra flexibility memorizing the noise term. Note also what the noise floor does: with noise of 0.3 baked into the labels, validation RMSE near 0.29 is about as good as any model can do here, which is the irreducible-error conversation in one number.
That train-vs-validation gap is the diagnostic interviewers want stated explicitly, it tells you which lever to pull, and the levers point in opposite directions. Fixing bias: richer features (holiday flags, lag features), more expressive model, less regularization. Fixing variance: regularization, early stopping, fewer/cleaner features, more training data, ensembling.
Then the FDE layer: customer pilots usually die on the variance side, for a sneaky reason, small pilot datasets. A customer hands you 800 labeled examples, a flexible model fits them beautifully, the demo dazzles, and week one in production looks nothing like the demo. So in deployments, your prior should lean toward simpler, higher-bias models early ("start with regularized logistic regression; it's also explainable to their compliance team"), and you let validation curves, not the demo wow-factor, tell you when to add capacity. Modern caveat worth one sentence: very large deep models can defy the classic U-curve (double descent), but for the tabular, mid-size-data problems FDEs actually deploy, the classical tradeoff governs.
What interviewers probe next
- "Customer gives you 10× more data, which error improves?", variance shrinks; bias doesn't move. If both train and validation error are high, more data is wasted budget; say so before they spend it.
- "How does regularization fit?", it deliberately adds bias to remove variance; net validation error often drops. Lambda is the dial.
- "Where does irreducible error fit?", label noise and inherent randomness; no model fixes it. Setting that expectation early protects the pilot's success criteria.
- "Learning curves?", plot error vs training-set size; converged-but-high curves mean bias, a persistent gap means variance. It's the cheapest artifact for justifying a data-collection ask to a customer.
Common mistakes
Defining the terms without the train/validation diagnostic, interviewers are testing whether you can detect the problem, not define it. Claiming more data fixes everything. Treating "complex model = better" as a default, at Google and Databricks, recommending the simpler model with a migration path reads senior. And ignoring the customer dimension entirely: a high-variance model that's right on the demo and erratic in production burns trust you can't regularize back.