Online learning: the DS interview answer

Why interviewers ask about online learning

When a Stripe or DoorDash interviewer slides over the prompt "walk me through how you'd build a fraud model that adapts in minutes, not weeks", they are testing whether you know the difference between batch training, online updates, and the half-dozen things that go wrong between them. The question filters senior DS candidates from juniors who only know model.fit() once a week on a Jupyter notebook.

The other reason: most real ML systems at companies like Uber, Netflix, and OpenAI are not pure batch anymore. Recsys, ranking, ad bidding, and anomaly pipelines all rely on incremental updates — sometimes per request, sometimes per minute. If you can articulate when streaming updates beat a nightly retrain and when they don't, you're already in the top quartile of candidates.

Batch vs online: the mental model

In batch learning you train on a fixed dataset, freeze the weights, then serve. Retraining happens on a schedule — daily, weekly, or whenever someone runs the DAG. The advantage is reproducibility and clean evaluation. The cost is staleness: anything that changed in the last 24 hours is invisible to the model.

In online learning you process samples one at a time (or in mini-batches of 32–1000) and update parameters after each. There is no "training set" — there is a stream and a model that keeps moving. This is the right paradigm when the data distribution drifts faster than your retraining schedule, or when the dataset literally does not fit in memory.

# Batch style — what every tutorial shows
model = LogisticRegression()
model.fit(X_train, y_train)
preds = model.predict(X_test)

# Online style — what production looks like
for x, y in stream:
    pred = model.predict_one(x)
    model.learn_one(x, y)   # parameters move every sample

The subtle thing interviewers want you to mention: in online mode, your "test set" is the next sample you have not seen yet. Standard k-fold CV does not apply — use prequential evaluation, where each sample is predicted first, then learned from.

Core algorithms you should name

SGD (Stochastic Gradient Descent). The simplest online learner: one gradient step per sample. In scikit-learn, SGDClassifier.partial_fit is the canonical entry point. Tune learning_rate='optimal' for stationary streams, 'adaptive' when drift is expected.

from sklearn.linear_model import SGDClassifier
clf = SGDClassifier(loss="log_loss", learning_rate="adaptive", eta0=0.01)
for x_batch, y_batch in stream:
    clf.partial_fit(x_batch, y_batch, classes=[0, 1])

FTRL-Proximal (Follow The Regularized Leader). Google's workhorse for CTR prediction. Combines per-coordinate adaptive learning rates with L1 regularization, which keeps the model sparse at billion-feature scale. If the role touches ads or ranking, name-drop FTRL — it signals you've read McMahan 2013.

Vowpal Wabbit. A C++ binary plus Python wrapper, optimized for billions of features and millions of samples per minute. Supports hashing tricks, contextual bandits, and active learning out of the box. Slightly cult-classic, but still production at major ad tech shops.

Online k-means and BIRCH. Clustering algorithms that maintain centroids incrementally. Useful for streaming segmentation where you cannot reload the whole user base.

Contextual bandits. Already online by design — every action gives a reward, the policy updates. LinUCB and Thompson sampling are the go-to algorithms; they sit at the boundary between online supervised learning and reinforcement learning.

Where online learning actually ships

Click-through rate prediction. Every impression at Meta, Google, or TikTok updates feature counters and (in some setups) model weights. The signal is fresh in seconds — batch retraining would lose hundreds of millions in revenue per quarter.

Recommendation systems. Two-tower models are typically batch-trained, but the scoring layer and re-rankers often consume streaming user signals (last 10 watches, dwell time in the last minute). At Netflix scale, even minutes of staleness shows up in retention metrics.

Fraud and abuse detection. Stripe Radar and similar systems blend a batch model with online features that update per transaction. Attackers iterate in hours; a weekly retrain is a guaranteed loss.

Anomaly detection on telemetry. Datadog, Honeycomb, and internal SRE tooling at every large company maintain rolling baselines per metric. Pure batch would generate false positives every Monday morning when traffic shape changes.

IoT and sensor data. A factory floor or a Tesla fleet emits more data per day than fits on one machine. Online learning is not a preference here — it is the only architecture that scales.

Concept drift and forgetting

Concept drift means the relationship P(y | x) changes over time. Online learning handles it natively if you tune the forgetting mechanism. Without forgetting, an online model just averages everything and behaves like a slow batch model.

Three forgetting strategies show up on whiteboards:

Sliding window. Keep the last N samples (or last T seconds) as the effective training set. Simple, predictable, and trivially explainable to a PM. Downside: discrete drop when an old sample leaves the window.

Exponential decay. Weight each sample by exp(-λ · age). Smoother than a window, and the half-life parameter λ maps directly to a business intuition ("the model forgets last week in 7 days"). This is what most adaptive learning rate schedulers approximate.

Ensembles of online learners. Maintain several models of different "ages" and combine their predictions. ADWIN, Learn++ NSE, and Dynamic Weighted Majority are the canonical names. Worth mentioning if the interviewer is from a research-heavy team.

Drift detection. You need a monitor regardless of which forgetting strategy you pick. Track rolling prequential accuracy or log-loss; trigger a reset (or a heavier retrain) when it crosses a threshold. ADWIN and Page-Hinkley are the textbook detectors; in practice, a Bayesian changepoint detector or a simple CUSUM on the loss works fine.

Tools and frameworks

river. The successor to creme, pure-Python, model API mirrors scikit-learn's learn_one / predict_one. Best fit for prototyping and small-to-medium streams.

from river import linear_model, metrics, preprocessing

model = preprocessing.StandardScaler() | linear_model.LogisticRegression()
metric = metrics.ROCAUC()

for x, y in stream:
    pred = model.predict_proba_one(x)
    metric.update(y, pred)
    model.learn_one(x, y)

Vowpal Wabbit. CLI plus Python bindings, scales to billions of features. Pick it when raw throughput matters more than ergonomics.

Spark Structured Streaming + MLlib. JVM-native, integrates with Kafka and Delta Lake. Best when the rest of the platform is already on Databricks or Snowflake's Snowpark.

TensorFlow / PyTorch with partial_fit patterns. Deep models are usually retrained periodically, but the embedding layers and the final head can absorb online updates with careful learning-rate scheduling. Meta's DLRM and similar architectures use this hybrid pattern.

Common pitfalls

The most common pitfall is confusing online inference with online learning. A model can serve predictions in 5 ms without updating a single parameter — that is just a fast batch model. The interviewer is asking about parameter updates, so be explicit: "the weights move on every sample" or "the weights are frozen, only the features are real-time." Conflating the two is the fastest way to lose a senior signal.

Another frequent trap is leaking the label into the features. In a streaming setup it is tempting to compute "rolling conversion rate by user" as a feature — but if that rolling rate includes the current sample, you have leaked the target. The fix is to lag every aggregated feature by at least one event and to enforce it with assertions in the feature store.

A third pitfall is not monitoring prequential loss. Teams set up an online pipeline, see throughput, declare victory, and never notice that the model has been drifting toward predicting a constant for the last week. Always log rolling AUC, log-loss, or calibration error per window, with alerts when they cross a sane threshold.

A fourth is catastrophic forgetting in deep online models. Neural networks updated naively on each sample will overwrite earlier knowledge — this is the same failure mode that breaks continual learning research. Mitigations include replay buffers, elastic weight consolidation, and freezing lower layers. For tabular models with SGD, this is rarely an issue, but mention it if you're asked about deep online ranking.

A fifth pitfall is assuming distributed online learning is free. Synchronizing parameter updates across workers introduces staleness — and stale gradients can destabilize training. Parameter servers, Hogwild!, and gradient compression are the patterns to know; pretending it scales trivially is a junior tell.

Related reading

• Data drift on DS interviews
• Multi-armed bandit for DS
• Cross-validation strategies for DS
• How to calculate distribution drift in SQL
• Kafka Streams for data engineering interviews

If you want to drill questions like this every day, NAILDD is launching with 500+ DS interview problems covering exactly these streaming-ML patterns.

FAQ

What is the difference between online learning and incremental learning?

In most modern usage they are synonyms. Some authors reserve incremental for periodic mini-batch updates (every 1000 samples) and online for true per-sample updates, but the line is fuzzy. If asked, say "I use them interchangeably, with the caveat that pure per-sample updates have different numerical stability properties than mini-batch."

Is online learning the same as reinforcement learning?

No. Online learning is supervised — you receive (x, y) pairs from a stream. Reinforcement learning is interactive — you take an action and receive a reward, and your action influences the next state. Contextual bandits sit between the two and are often the right choice for ranking and recommendations where you only see rewards for the items you showed.

When should I prefer a nightly batch retrain over true online updates?

When the data distribution is stable on a 24-hour horizon, when your team's MLOps maturity is low, or when reproducibility for audit reasons matters more than freshness. Most BI-style models (churn prediction, LTV regression) live happily in batch. Switch to online only when the cost of staleness — measured in dollars or user experience — exceeds the operational cost of streaming infrastructure.

How do I evaluate an online model without a held-out test set?

Use prequential evaluation: for each incoming sample, predict first, score against the true label, then update. Maintain rolling metrics over the last N samples or last T minutes. For unbiased estimates, ADWIN-based windowing automatically adapts the window length to drift. Avoid the rookie mistake of reusing the same sample for both eval and training in the same step.

How do I handle class imbalance in a streaming setting?

Reservoir sampling for the minority class, per-class learning rates, or focal loss in the online update. Static oversampling does not work because you do not have the full dataset. A practical pattern is to maintain a small reservoir buffer of recent positives and replay them at every step — cheap, effective, and easy to explain.

Does online learning work for deep neural networks?

It works, but with caveats. Pure per-sample SGD on a large transformer will be slow and unstable. The production pattern is mini-batch online: buffer 128–1024 samples, do one gradient step, repeat. Add a replay buffer to prevent catastrophic forgetting, and freeze the lower layers if you only want the head to adapt. Meta, TikTok, and major recsys teams ship variants of this.