Bayesian optimization on the data science interview

Why interviewers ask this

When a hiring manager at Stripe, DoorDash, or Netflix asks about Bayesian optimization, they are not testing whether you can recite the closed-form posterior of a Gaussian Process. They are checking whether you understand that hyperparameter tuning is a sample-efficiency problem, and whether you reach for the right tool when each training run costs an hour of GPU time. A senior data scientist who still tunes XGBoost with a 5x5x5 grid on a 200-million-row table is signalling that they have not owned an expensive model in production.

The second reason is that Bayesian optimization sits at the boundary of three areas the interview loop wants to probe at once: classical machine learning, probabilistic modelling, and engineering trade-offs. A clean answer touches all three. You say what the surrogate is, you explain how the acquisition function balances exploration and exploitation, and you mention which library you would reach for on day one — typically Optuna with the default TPE sampler, not a hand-rolled GP.

A concrete scenario: a US fintech team trains a churn model that takes 40 minutes per fold of cross-validation. With five folds and twelve hyperparameters, a modest random search of 200 trials burns roughly 660 hours of compute. If Bayesian optimization can reach the same loss in 30 trials, the interviewer wants you to explain why — and to size the savings without a whiteboard.

Grid, random, Bayesian — the gap

Hyperparameter tuning is the problem of finding the input vector x that minimises a function f(x), where f returns a validation metric and each call to f is expensive. The function has no analytical form, the gradient is unavailable, and the search space is a mix of continuous, integer, and categorical dimensions. That setup rules out gradient descent and motivates three families of strategy.

Grid search enumerates a Cartesian product of candidate values. It is the easiest to reason about and the worst at scale: the number of trials grows exponentially with the number of hyperparameters, and most of the budget is spent on combinations where one dimension dominates the metric and the others are irrelevant. Bergstra and Bengio showed in 2012 that random search beats grid search on the same budget whenever only a few of the hyperparameters actually matter, which is almost always the case for tree boosters and deep networks.

Random search samples each trial independently from a prior over the search space. It is embarrassingly parallel, has no warm-up cost, and is the right baseline against which Bayesian optimization should be benchmarked. The weakness is that random search has no memory: trial 200 is no smarter than trial 1, even though the previous 199 observations contain rich information about which regions of the space are promising.

Bayesian optimization closes that gap by building a probabilistic model of f from past observations and using that model to choose the next trial. The loop has five steps and you should be able to recite it cold in an interview.

1. Sample a small number of initial points (10-20) randomly.
2. Fit a surrogate model to the observed (x, f(x)) pairs.
3. Optimise an acquisition function over the surrogate to pick the next x.
4. Evaluate f(x) — train the model and observe the validation metric.
5. Append the observation, refit the surrogate, return to step 3.

The interesting work happens in steps 2 and 3. Pick the wrong surrogate and the model misreads the landscape. Pick the wrong acquisition function and you either over-exploit a local minimum or wander forever in unexplored regions.

The surrogate — Gaussian Process

A Gaussian Process is a non-parametric prior over functions. Given a set of n observations, the GP posterior at any unseen point x is itself a Gaussian distribution with a mean mu(x) and a variance sigma squared (x). The mean is the model's best guess for f(x); the variance encodes how confident it is. Far from any observation, variance is high. Near observed points, variance shrinks toward zero.

The kernel — usually a Matern 5/2 or a squared exponential — controls how strongly nearby points are assumed to be correlated. The kernel hyperparameters (length scale, output scale, observation noise) are themselves fitted by maximising the marginal likelihood, which is why fitting a GP gets noticeably slower past a few hundred observations: the cost is cubic in the number of points.

from sklearn.gaussian_process import GaussianProcessRegressor
from sklearn.gaussian_process.kernels import Matern, ConstantKernel

kernel = ConstantKernel(1.0) * Matern(length_scale=1.0, nu=2.5)
gp = GaussianProcessRegressor(kernel=kernel, normalize_y=True, n_restarts_optimizer=5)
gp.fit(X_observed, y_observed)

mu, sigma = gp.predict(X_candidate, return_std=True)

For a Bayesian optimization loop with 30 to 100 trials and fewer than 20 dimensions, a GP surrogate is excellent. Past that, two things break: the cubic cost dominates, and the kernel struggles to model discrete or conditional hyperparameters (for example, "use dropout" being a boolean that controls whether "dropout rate" is even active). That is where TPE takes over, and it is the answer the interviewer is hoping to hear when they ask why Optuna does not default to GP.

Acquisition functions

An acquisition function maps the surrogate's posterior at x to a scalar that quantifies how worthwhile it would be to evaluate f at x next. The argmax of the acquisition function is the next trial. Three formulations come up repeatedly in interviews.

Expected Improvement is the most widely used. It computes the expected amount by which f(x) would improve over the current best observation f_best, integrating over the surrogate's posterior at x. Points where the mean is already below f_best score high; points with huge variance also score high, because the upper tail of their posterior has a chance to dip below f_best.

EI(x) = E[max(0, f_best - f(x))]

For a Gaussian posterior the integral has a closed form involving the standard normal CDF and PDF, which makes EI cheap to compute and easy to optimise with a multi-start L-BFGS over the search space.

Upper Confidence Bound trades transparency for simplicity. It scores x as mu(x) minus a coefficient kappa times sigma(x) when minimising, or mu(x) plus kappa sigma(x) when maximising. The kappa parameter dials the explore-exploit balance directly: a small kappa exploits, a large kappa explores. Srinivas et al. proved regret bounds for GP-UCB with a kappa schedule that grows logarithmically with the number of trials, and that is the version you should mention if asked for a theoretical justification.

Probability of Improvement is the older sibling of EI. It computes the probability that f(x) is below f_best, without weighting by the magnitude of the improvement. PI is well-known to over-exploit: it happily samples points marginally better than f_best while ignoring uncertain regions that could hide a much deeper minimum. Use it as a baseline, not a default.

Optuna and TPE in practice

In the real interview, the follow-up after "what is Bayesian optimization" is "what library would you use". The answer should be Optuna, and it should be specific about the sampler.

import optuna

def objective(trial):
    params = {
        "learning_rate": trial.suggest_float("learning_rate", 1e-3, 0.3, log=True),
        "max_depth": trial.suggest_int("max_depth", 3, 12),
        "num_leaves": trial.suggest_int("num_leaves", 16, 256, log=True),
        "min_child_samples": trial.suggest_int("min_child_samples", 5, 200),
        "subsample": trial.suggest_float("subsample", 0.5, 1.0),
    }
    model = train_lightgbm(params, X_train, y_train)
    return cross_val_auc(model, X_valid, y_valid)

sampler = optuna.samplers.TPESampler(seed=42, multivariate=True, n_startup_trials=20)
study = optuna.create_study(direction="maximize", sampler=sampler)
study.optimize(objective, n_trials=100, n_jobs=4)

Optuna's default sampler is the Tree-structured Parzen Estimator, not a Gaussian Process. TPE models two densities — one over hyperparameters that produced good metrics and one over the rest — and then picks the next trial that maximises their ratio. TPE handles mixed continuous, integer, and categorical search spaces natively, scales linearly in the number of trials, and tolerates conditional dimensions where some hyperparameters are only relevant given the values of others. For most tabular ML problems at Anthropic, Notion, or Airbnb scale, TPE is the right default. Switch to a GP-based sampler only when the search space is fully continuous, low-dimensional, and each trial is genuinely expensive.

Hyperopt is the predecessor library and still works, but its API is less ergonomic and its visualisations are weaker. Ray Tune wraps Optuna, Hyperopt, and a dozen other samplers, and is the right choice when you need distributed tuning across a cluster — for example, when DoorDash tunes a ranking model across 200 GPUs and needs early stopping coordinated across workers.

Common pitfalls

The most common failure mode in production is starting Bayesian optimization with too few initial random trials. Teams set n_startup_trials to 5 and then wonder why the surrogate keeps recommending the same corner of the space. With fewer than ten well-spread initial points the surrogate has almost no idea what f looks like, the acquisition function exploits a noisy region, and the loop converges prematurely. A safe default is 15 to 25 random trials before the surrogate takes over, scaled with the dimensionality of the search space.

A related trap is forgetting that the validation metric is itself noisy. Cross-validation scores fluctuate from fold to fold, and a single seed of stochastic gradient descent introduces additional variance. If the noise in f is larger than the typical improvement between trials, the optimiser will chase noise. The fix is twofold: report the metric averaged over multiple folds or seeds inside the objective, and tell the optimiser the observation noise explicitly (Optuna exposes this through the GP-based samplers, and TPE handles it implicitly by smoothing the density estimate).

A third pitfall is treating the search space as if all dimensions were equally important. In practice, learning rate and tree depth typically dominate, while regularisation parameters at the extremes of their ranges contribute almost nothing. Inspecting the parameter importance after a run — Optuna exposes this through fANOVA — saves enormous compute on the next iteration of the project, because you can shrink or drop irrelevant dimensions.

A fourth trap is running Bayesian optimization on a problem where each evaluation is cheap. If a single trial takes two seconds, the overhead of fitting a GP and optimising EI dwarfs the savings, and a 5000-trial random search will reach the same optimum faster on wall-clock time. The surrogate only pays for itself when each evaluation is expensive enough to justify it.

The final mistake is forgetting to seed the sampler and report the seed alongside the best trial. Without a seed, the result is irreproducible, the colleague reviewing the experiment cannot rerun it, and the interviewer who notices will ask why your offline ML workflow does not match the rigour you would expect from an A/B test.

Applications beyond ML

The same machinery shows up outside hyperparameter tuning. Anthropic and OpenAI use Bayesian optimization variants for neural architecture search, where each evaluation is a partial training run of a candidate architecture. Tesla and applied-physics teams use it for engineering design — battery cell geometry, body panel curvature, wind tunnel layout — because each evaluation is a finite-element simulation that costs real money.

In experimentation, Bayesian methods underpin adaptive A/B test designs where treatment allocation shifts toward the better arm as evidence accumulates. The acquisition function in that setting becomes Thompson sampling or a Bayes-UCB variant, but the mental model is the same: balance exploration against exploitation under uncertainty, on a budget.

Related reading

• Bayesian methods for the data science interview
• Bayes theorem explained simply
• A/B testing peeking mistake
• SQL window functions interview questions

If you want to drill DS interview questions like this every day, NAILDD is launching with 500+ problems across exactly this pattern.

FAQ

When should I pick TPE over a Gaussian Process surrogate?

Pick TPE when the search space contains integer, categorical, or conditional hyperparameters, when you expect to run more than about a hundred trials, or when you want to parallelise trials without coordinating posterior updates. GP wins when the space is fully continuous, low-dimensional (say, six or fewer parameters), and each trial is so expensive that the cubic cost of fitting the GP is negligible compared to a single evaluation.

How many trials does Bayesian optimization actually need?

For a typical XGBoost or LightGBM tuning problem with eight to twelve hyperparameters, 30 to 100 trials usually saturates. For deep learning with twenty-plus hyperparameters and conditional structure, plan for 100 to 300 trials and use early stopping aggressively. The honest answer to give in an interview is "I'd run a small pilot to see when the best-so-far curve plateaus".

Does Bayesian optimization support parallel trials?

Yes, but with care. Plain Bayesian optimization is sequential by construction — the next trial depends on the previous result. To parallelise, the sampler either returns several candidates at once using a batch acquisition function (qEI) or pretends pending trials have completed with imputed values until the real result arrives. Optuna handles both modes through the n_jobs argument and the constant-liar heuristic.

What is the relationship between Bayesian optimization and reinforcement learning?

Both are sequential decision-making under uncertainty, but the budget and the structure differ. Bayesian optimization assumes a static, expensive objective and a budget of tens to hundreds of evaluations; reinforcement learning assumes a dynamic environment, a reward signal at every step, and budgets of millions of interactions. The exploration-exploitation trade-off is the shared idea; the algorithms diverge from there.

Is the worked example official Optuna guidance?

The code follows patterns in the Optuna user guide for TPE. Theoretical claims about GP-UCB come from Srinivas et al. (2010) and the Snoek-Larochelle-Adams paper (2012). Treat the numbers as orders of magnitude, not benchmarks.