Lyft Data Scientist Interview Preparation Guide - Mid Level (2-5 Years)

Direct answer
Detecting forecast bias means checking whether forecast errors are systematically one-directional over time (not just noisy around zero), using a mean-percentage-error tracking signal and a formal significance test, setting an action threshold, and applying a correction (recalibration, an explicit bias term, or retraining) once bias is confirmed.

Structured elaboration and worked example (executed)
Against a synthetic 24-month series with a genuine, injected +6% systematic under-forecast bias:

pct_error = (y_true - y_pred) / y_true * 100     # positive = under-forecast
t_stat, p_value = stats.ttest_1samp(pct_error, popmean=0)

Executed result:

mean percentage error (bias): 6.33%  (true injected bias: 6.0%)
one-sample t-test vs 0 (H0: no systematic bias): t=49.452, p=0.00000
-> statistically significant bias

The measured bias (6.33%) closely recovers the true injected 6%, and the one-sample t-test against zero decisively rejects "no bias" (p far below any reasonable threshold) - this is the core statistical mechanic: don't just eyeball a mean-error number, test whether it's distinguishable from zero given the observed variance, since a small sample or high-variance series can produce a nonzero-looking average purely by chance.

• Metrics to compute: mean error (in native units) and mean PERCENTAGE error (signed, not absolute - absolute error can't reveal a systematic DIRECTION, only overall magnitude) are the two core bias-tracking signals; track both over a rolling window, not just all-time, since bias can emerge or resolve over time.
• Statistical tests/tracking signals: a one-sample t-test against zero (as above) formalizes "is this bias distinguishable from noise"; a tracking signal (cumulative sum of forecast errors divided by mean absolute deviation) is a classical alternative that flags a running total drifting persistently away from zero, functionally similar in spirit to CUSUM.
• Setting thresholds for action: define both a STATISTICAL threshold (p < 0.05, or your chosen significance level) and a PRACTICAL threshold (bias small enough in absolute/business terms not to matter even if technically significant) - with enough data, even a trivially small bias can become statistically significant, so both checks matter, not just the p-value.
• Corrective measures: recalibration (apply a simple multiplicative or additive correction factor once bias is confirmed stable), an explicit bias term added to a model that structurally can't otherwise represent it, or full retraining if the bias reflects a genuine change in the underlying process rather than a fixable calibration offset.
• SQL per-SKU computation: the same logic (mean error, mean percentage error) computes directly in SQL with AVG(actual - forecast) and AVG((actual - forecast) / actual) grouped by SKU; a real implementation trap surfaced by testing this exact query: filtering NULL actuals in the WHERE clause BEFORE grouping silently prevents you from also counting how many rows were excluded in the same query (the excluded rows are gone before the aggregate ever sees them) - the fix is to move the NULL-exclusion into the aggregate itself (AVG(CASE WHEN actual IS NOT NULL THEN ... END) alongside a separate SUM(CASE WHEN actual IS NULL THEN 1 ELSE 0 END)), which correctly reports both the bias AND the exclusion count from one query. Running the WHERE-based version against a table with one deliberately NULL row reports 0 excluded; the CASE-based fix correctly reports 1.

Trade-offs & pitfalls
Bias by region or product line should be checked SEPARATELY, not just in aggregate - a portfolio that's unbiased on average can hide an offsetting +10%/-10% bias across two segments, which is invisible to an aggregate check but very real operationally for each segment. And a corrective bias term added once should be revisited periodically, not applied and forgotten: if the underlying cause resolves (e.g. a one-off supply issue is fixed), a stale correction factor becomes a NEW source of bias in the opposite direction.

Approach summary: use a Bayesian hierarchical (multilevel) log-log regression so coefficients are price elasticities. Allow random intercepts and random slopes by customer segment to share strength across segments while capturing heterogeneity.

Model formulation (log-log):
y_ij = log(q_ij) (quantity for observation i in segment j)
x_ij = log(p_ij) (price)
y_ij ~ Normal(α_j + β_j * x_ij + γ' z_ij, σ_y)
[α_j, β_j] ~ MultivariateNormal([α_pop, β_pop], Σ_segment)
γ ~ Normal(0, σ_γ) (fixed effects for controls: promotions, seasonality, etc.)

Priors / regularization:
α_pop ~ Normal(0, 5)
β_pop ~ Normal(-1, 1) (centered near typical elasticity)
Σ_segment = diag(σ_α, σ_β) * R * diag(σ_α, σ_β)
σ_α, σ_β ~ HalfNormal(1)
R ~ LKJ(2) for correlation
σ_y ~ HalfNormal(1)

Pooling behavior:

• Partial pooling: segments with little data shrink toward population means; well-sampled segments retain their own estimates.
• Correlated random effects let intercept and slope covary (e.g., higher baseline demand linked to different elasticity).

Data requirements per segment:

• Minimum: ~30–50 observations to estimate segment slope reliably; more needed if high noise or many covariates.
• If segments have fewer observations, consider grouping or hierarchical predictors (e.g., region-level predictors) or inform priors with domain knowledge.

Presentation to product/pricing teams:

• Show segment-level posterior summaries: mean elasticity, 95% credible intervals, probability elasticity < -1 (elastic) etc.
• Visuals: caterpillar plot of β_j with CI sorted by elasticity; scatter of segment size vs. elasticity uncertainty; counterfactual demand curves for representative segments (simulate price change → % revenue/volume impact).
• Actionable recommendations: prioritize segments with high elasticity and sufficient volume for targeted discounts; quantify expected revenue lift/loss with uncertainty bands.
• Provide simple rule-of-thumb and next steps (A/B test buckets, collect more data for uncertain segments).

Example PyMC model skeleton:

import pymc as pm

with pm.Model() as model:
    alpha_pop = pm.Normal("alpha_pop", 0, 5)
    beta_pop = pm.Normal("beta_pop", -1, 1)
    sigma_alpha = pm.HalfNormal("sigma_alpha", 1)
    sigma_beta = pm.HalfNormal("sigma_beta", 1)
    packed = pm.LKJCholeskyCov("L", n=2, eta=2, sd_dist=pm.HalfNormal.dist(1))
    L = pm.expand_packed_triangular(2, packed)
    sigma_y = pm.HalfNormal("sigma_y", 1)

    seg_idx = ...  # integer segment mapping
    mu_ab = pm.MvNormal("mu_ab", mu=[alpha_pop, beta_pop], chol=L, shape=(n_segments,2))
    alpha_j = mu_ab[seg_idx,0]
    beta_j = mu_ab[seg_idx,1]

    mu = alpha_j + beta_j * x + pm.math.dot(Z, gamma)
    y_obs = pm.Normal("y_obs", mu, sigma_y, observed=y)

MLflow provides four components that cover the ML lifecycle: Tracking, Projects, Models, and Model Registry. For each:

1. Tracking — records experiments (params, metrics, artifacts).
   Example: I run hyperparameter sweeps for a scikit-learn model and log learning_rate, max_depth, validation AUC, and feature-importance plots to MLflow. I compare runs in the UI to pick the best hyperparameters.

2. Projects — packages code and environment for reproducible runs.
   Example: I create an MLproject file pointing to a conda environment and an entry point train. Colleagues can reproduce a run with mlflow run . or CI can execute the same job with identical dependencies.

3. Models — standardizes how models and artifacts are saved and loaded.
   Example: After training, I save the model with mlflow.sklearn.log_model(model, "model") so the model, signature, and example input are stored. Later I load it with mlflow.pyfunc.load_model for batch inference.

4. Model Registry — lifecycle and governance for models (staging, production, versions).
   Example: I register the best run’s model, promote version 3 to "Staging" for integration tests, then to "Production" after validation. Registry keeps version history, annotations, and supports rollbacks.

Together they enable reproducible experiments, collaborative packaging, consistent model deployment, and governed promotion to production.

Direct answer
Beyond word choice, deliberate pacing, brief pauses at key transitions, and periodic checkpoints where you invite a question all help a live audience stay oriented during a longer explanation.

Structured elaboration

• Pacing: slowing down slightly at the most important sentence (a conclusion, a number, a decision point) signals to the listener that this part matters more than the surrounding context, the same way bolding a phrase does on a page.
• Pauses at transitions: a brief pause when moving from one idea to the next gives the listener a moment to finish processing the previous point instead of having it run together with the next one.
• Checkpoints for questions: explicitly stopping every few minutes to ask "does that make sense so far, any questions before I move on?" catches confusion early, while it's still cheap to address, rather than at the end when the listener has been lost for a while.
• Choosing two or three of these deliberately, rather than trying to do everything at once, is more sustainable; trying to consciously manage every aspect of delivery simultaneously tends to make a speaker sound stilted.

Worked example
During a fifteen-minute technical walkthrough: slow down and pause briefly right before stating the recommendation ("...and so, the option we're proposing is [pause] option two"), then at the two natural section breaks (after background, and after the options), stop explicitly and ask "any questions before I move to the next part?" rather than only checking in at the very end.

Trade-offs and pitfalls

• Overusing dramatic pauses or slowing down on things that aren't actually the key point dilutes the technique; it works because it's used selectively.
• Checkpoints can eat into your time budget if the audience takes them as an invitation for a lengthy tangent; it can help to explicitly frame them as "quick check" rather than opening the floor fully.
• These techniques don't substitute for a clear structure; a well-paced explanation of a confusing structure is still confusing, just more pleasant to listen to.

Direct answer

An online ECE calculator updates per-bin counts (predictions and correct outcomes) incrementally as each new example arrives, and computes Expected Calibration Error on demand as the sample-size-weighted average gap between each bin's average confidence and its observed accuracy.

Structured elaboration

class CalibrationMonitor:
    def __init__(self, num_bins: int = 10):
        self.num_bins = num_bins
        self.bin_confidence_sum = [0.0] * num_bins
        self.bin_correct_sum = [0.0] * num_bins
        self.bin_count = [0] * num_bins

    def _bin_index(self, confidence: float) -> int:
        # clip to [0, 1) to avoid an out-of-range index at exactly confidence == 1.0
        clipped = min(confidence, 0.9999999)
        return int(clipped * self.num_bins)

    def update(self, confidence: float, correct: bool):
        idx = self._bin_index(confidence)
        self.bin_confidence_sum[idx] += confidence
        self.bin_correct_sum[idx] += int(correct)
        self.bin_count[idx] += 1

    def ece(self) -> float:
        total_n = sum(self.bin_count)
        if total_n == 0:
            return float("nan")
        error = 0.0
        for i in range(self.num_bins):
            n = self.bin_count[i]
            if n == 0:
                continue  # a genuinely empty bin contributes nothing -- not a zero-confidence-gap claim
            avg_confidence = self.bin_confidence_sum[i] / n
            observed_accuracy = self.bin_correct_sum[i] / n
            error += (n / total_n) * abs(avg_confidence - observed_accuracy)
        return error

    def per_bin_report(self) -> list[dict]:
        return [
            {"bin": i, "avg_confidence": (self.bin_confidence_sum[i] / self.bin_count[i]) if self.bin_count[i] else None,
             "accuracy": (self.bin_correct_sum[i] / self.bin_count[i]) if self.bin_count[i] else None,
             "count": self.bin_count[i]}
            for i in range(self.num_bins)
        ]

Class imbalance robustness: this design tracks per-bin sample counts explicitly, so a bin with very few observations (common in a highly-imbalanced setting where confident-correct predictions for the majority class dominate, leaving sparse coverage in some confidence ranges) contributes proportionally LESS to the final ECE (via the n / total_n weight) rather than being treated as equally reliable evidence as a well-populated bin: this is the natural mitigation reservoir-based or bin-count-weighted ECE gives you for free.

Worked example

For a genuinely sparse bin (say, only 3 observations ever landing in the 0.9-1.0 confidence range for a rare minority class), the per_bin_report exposes that sparsity directly (count: 3) so a consumer of this monitor can judge for themselves whether that bin's contribution to the overall ECE is trustworthy: rather than the aggregate ECE number silently treating 3 observations as equally solid evidence as a bin with 10,000.

Trade-offs & pitfalls

A genuinely sparse bin's average confidence and accuracy, computed from only a handful of observations, is itself a noisy, unreliable estimate: the weighting by count reduces its influence on the AGGREGATE ECE, but doesn't fix the fact that the sparse bin's own reported gap could easily be wrong just from small-sample noise. A more careful production version would add a minimum-count threshold below which a bin's contribution is either excluded entirely or flagged with an explicit confidence interval, rather than silently including a noisy small-sample estimate in the weighted average, even at a reduced weight.

Situation: At my previous company the data science team worked in silos—different toolsets, duplicated preprocessing code, and inconsistent model deployment practices slowed projects.

Task: I led a monthly lunch-and-learn series to standardize best practices (feature engineering patterns, model evaluation, and an intro to our new feature store/MLOps pipeline) and increase cross-team knowledge sharing.

Action:

• Topic selection: surveyed DSs, engineers, and product managers to prioritize pain points; first three sessions focused on reproducible pipelines, feature store usage, and model monitoring.
• Format: 45-minute session — 25 min demo/code-along (Python + scikit-learn + our feature store CLI), 15 min Q&A, 5 min feedback poll; sessions were recorded and notes + runnable notebooks published to our Confluence and a GitHub repo.
• Engagement: made sessions hands-on with a small starter dataset, offered pizza for in-person attendance, incentivized contributions by rotating presenters and spotlighting a “practical tip” in team standups. I also created a Slack channel for follow-ups and office-hours for implementation help.

Result:

• Attendance averaged 30 people (cross-functional: 40% product/engineering), and within two months 5 of 7 DS projects adopted the feature store templates.
• Deployment lead time for models using the templates dropped from ~10 days to ~3 days on average.
• Cross-team tickets requesting model-monitoring integration increased by 60% (indicating awareness and collaboration).
• Team survey after three months showed a 25-point increase in confidence around reproducible pipelines.

Learning: Hands-on demos, accessible artifacts, and follow-up support are key to turning knowledge sessions into measurable adoption.

Direct answer: Join the legacy and new implementations' output on the shared date key, compute the percent difference per date, and where the difference exceeds 1%, run a set of automated diagnostic checks (missing partitions, NULL-handling differences, and a zero-baseline check) to populate a reason_code rather than leaving the discrepancy unexplained.

Structured elaboration and executable SQL:

WITH compared AS (
  SELECT l.date, l.value AS legacy_value, n.value AS new_value,
         CASE
           WHEN l.value IS NULL OR n.value IS NULL THEN NULL
           WHEN l.value = 0 THEN NULL
           ELSE ABS(l.value - n.value) * 1.0 / ABS(l.value)
         END AS pct_diff
  FROM legacy_metric l
  FULL OUTER JOIN new_metric n ON n.date = l.date
)
SELECT date, legacy_value, new_value, pct_diff,
  CASE
    WHEN legacy_value IS NULL THEN 'missing_in_legacy'
    WHEN new_value IS NULL THEN 'missing_in_new_partition'
    WHEN legacy_value = 0 AND new_value <> 0 THEN 'value_mismatch_zero_baseline'
    WHEN legacy_value = 0 AND new_value = 0 THEN 'within_tolerance'
    WHEN pct_diff > 0.01 THEN 'value_mismatch_over_threshold'
    ELSE 'within_tolerance'
  END AS reason_code
FROM compared
WHERE legacy_value IS NULL
   OR new_value IS NULL
   OR (legacy_value = 0 AND new_value <> 0)
   OR pct_diff > 0.01;

The reason_code column is what turns a bare list of mismatched dates into an ACTIONABLE list: "missing partition" points to a pipeline scheduling problem, "value_mismatch_zero_baseline" points to a case a plain percent-difference formula cannot express, and "value mismatch" points to an actual logic difference worth diffing the two SQL definitions for.

Worked example: if legacy_value=1000 and new_value=950 for a given date, pct_diff=0.05 (5%), correctly exceeding the 1% threshold and flagged value_mismatch_over_threshold; a date present in new_metric but entirely absent from legacy_metric (perhaps the new pipeline started a day earlier) is flagged missing_in_legacy rather than silently excluded from the comparison. A date where legacy_value=0 and new_value=100 cannot be scored as a percent difference at all (dividing by zero is undefined), so a naive query that simply wraps the denominator in NULLIF(l.value, 0) turns that division into NULL and, because pct_diff > 0.01 is never true for a NULL value and neither legacy_value nor new_value is NULL, silently drops that row from the result entirely, exactly the kind of go-from-nothing-to-something regression this comparison exists to catch. The corrected query adds an explicit value_mismatch_zero_baseline branch so a former-zero metric that starts producing nonzero output (or vice versa) is always flagged, and a legitimate zero-to-zero date is still excluded as within_tolerance.

Trade-offs & pitfalls: Automate this as a nightly job comparing the trailing N days (enough to catch both immediate regressions and slower-arriving late data), storing the results in a small history table so a persistent, unresolved mismatch on the SAME dates over multiple nights escalates in priority differently than a one-off, likely-timing-related blip that resolves itself the next night once late data lands. During a migration period, this comparison should run for as long as BOTH pipelines remain live; cutting over the new pipeline before a sustained period of within_tolerance results is the most common way a genuine logic bug in the new pipeline goes undetected until well after the legacy pipeline (and the ability to easily compare) has been decommissioned. Never let a percent-difference formula's own division silently swallow the zero-baseline case; it is one of the most consequential mismatches to catch, not an edge case safe to ignore.

Direct answer

Build the check as a set of explicit boolean conditions, one per issue type (negative price, missing currency, unsupported currency), tag each row with which conditions it violates, and then aggregate those tags into a per-issue-type count. Keep the row-level flags and the summary as two separate query outputs: the flagged rows for someone to act on, and the summary counts for a quick health read.

Structured elaboration

1. Define each issue as an explicit boolean, not a single catch-all WHERE. A row can fail more than one check at once, and you want to know that.
2. Surface the flagged rows with the boolean columns attached, so a reviewer can see exactly why a row was flagged without re-deriving it.
3. Summarize by issue type using UNION ALL (or COUNT(*) FILTER (WHERE ...) per condition) so the output answers "how many rows have issue X" even when a row has more than one issue and would otherwise be double-counted in a naive single-condition GROUP BY.
4. This is the same "flag, don't drop" instinct as any data-quality check: invalid rows get surfaced for a decision, not silently filtered out of the analysis.

The same pattern extends past value-range checks to logical-consistency checks, where the problem isn't that one field is invalid in isolation, but that two fields contradict each other (see the alternate scenario below).

Worked example

Seed data: 7 pricing rows, with a supported_currencies reference table containing USD, EUR, GBP.

SELECT
  price_id, product_id, unit_price, currency,
  unit_price < 0 AS is_negative_price,
  currency IS NULL AS is_missing_currency,
  (currency IS NOT NULL AND currency NOT IN (SELECT code FROM supported_currencies)) AS is_unsupported_currency
FROM pricing
WHERE unit_price < 0 OR currency IS NULL OR currency NOT IN (SELECT code FROM supported_currencies)
ORDER BY price_id;

Real output (4 of 7 rows flagged):

Row 5 shows why a single-issue summary would undercount: it's both negative and unsupported currency.

WITH flagged AS (
  SELECT price_id,
    unit_price < 0 AS is_negative_price,
    currency IS NULL AS is_missing_currency,
    (currency IS NOT NULL AND currency NOT IN (SELECT code FROM supported_currencies)) AS is_unsupported_currency
  FROM pricing
)
SELECT 'negative_price' AS issue_type, COUNT(*) FILTER (WHERE is_negative_price) AS row_count FROM flagged
UNION ALL
SELECT 'missing_currency', COUNT(*) FILTER (WHERE is_missing_currency) FROM flagged
UNION ALL
SELECT 'unsupported_currency', COUNT(*) FILTER (WHERE is_unsupported_currency) FROM flagged
ORDER BY row_count DESC;

Real output:

Row 5 correctly contributes to both negative_price and unsupported_currency, so the totals sum to 5, not 4 (the number of distinct flagged rows).

Alternate scenario: a logical-consistency check

The absorbed variant asks about a row where closed_at is set but stage contradicts it, a different flavor of invalid value: not a bad single value, but two fields disagreeing with each other.

SELECT opp_id, stage, closed_at,
  CASE
    WHEN stage IN ('won','lost') AND closed_at IS NULL THEN 'CLOSED_STAGE_MISSING_DATE'
    WHEN stage = 'open' AND closed_at IS NOT NULL THEN 'OPEN_STAGE_HAS_CLOSE_DATE'
    ELSE 'OK'
  END AS consistency_flag
FROM opportunities ORDER BY opp_id;

Real output:

Same "flag every violated condition explicitly" instinct as the pricing check, just applied across two columns instead of within one.

Trade-offs & pitfalls

• A single WHERE unit_price < 0 OR currency IS NULL OR ... with a GROUP BY on a single derived reason string undercounts multi-issue rows; keep each condition as its own boolean so a row can count toward every issue it actually has.
• Deciding what to do with flagged rows (block the load, quarantine to a side table, or just alert) is a separate policy decision from detection; don't conflate "this looks wrong" with "here's what to do about it" in the same query.
• NOT IN (SELECT ...) against a reference table with any NULLs in it returns no rows at all (a classic SQL trap): if supported_currencies.code could ever contain a NULL, use NOT IN (SELECT code FROM supported_currencies WHERE code IS NOT NULL) or rewrite as a NOT EXISTS.

Direct answer: Hand-engineered features still beat learned representations when labeled data is scarce, when domain knowledge encodes a real constraint the model would otherwise have to rediscover from scratch, or when interpretability is required; letting a model learn its own representation wins when there's abundant data, the raw input is naturally structured for representation learning (images, text, audio), and the modeling team can afford the extra compute and complexity.

Structured elaboration:
The case FOR hand engineering: with a small or moderate labeled dataset, a deep model has to learn both the useful representation AND the mapping to the target from the same limited signal, while a hand-crafted feature bakes in domain knowledge (a known physical relationship, a known business ratio) directly, effectively acting as a strong prior that a data-starved model can't discover on its own. It's also usually far more interpretable and cheaper to compute and serve.

The case FOR learned representations: with abundant data and a naturally unstructured input (raw pixels, raw text, raw audio), a deep model can discover interactions and structure a human wouldn't think to hand-craft, and often outperforms manual feature engineering specifically in that regime, at the cost of needing much more data, compute, and generally sacrificing some interpretability.

Two concrete cases where hand-engineering wins:

1. Tabular click-through-rate prediction with a modest dataset and known domain ratios: a hand-engineered feature like click-through-rate normalized by historical impression volume typically outperforms a deep model trying to learn the same relationship from raw counts, because the ratio encodes exactly the right inductive bias a small dataset can't teach the model on its own.
2. Fraud detection with a small number of confirmed fraud labels and known rule-based domain signals (e.g. transaction amount relative to a customer's trailing 90-day average, or velocity of transactions in the last hour): with only a few hundred or thousand confirmed fraud examples, a deep model attempting to learn these relationships from raw transaction fields directly tends to underperform a small tree-based model fed these explicit ratio/velocity features, because the label scarcity leaves too little signal for the model to discover the relationship unaided, while the hand-engineered ratio is designed to expose it directly.

Two concrete cases where letting the model learn wins:

1. Image classification with millions of labeled examples: a convolutional or transformer-based model learning its own visual features from raw pixels reliably outperforms any hand-crafted image feature (edge detectors, color histograms) a person could design, because there's enough data for the model to discover far richer structure than manual engineering would ever specify.
2. Large-scale text classification or language modeling with a large labeled or self-supervised corpus: a transformer learning its own token/sentence representations from raw text outperforms a hand-engineered bag-of-words-plus-manual-rules approach, because the volume of text lets the model capture context, negation, and long-range dependencies that manual feature design (keyword counts, fixed n-gram lists) can't practically enumerate.

Trade-offs and pitfalls: The decision isn't purely binary in practice: most production tabular systems benefit from SOME hand engineering (ratios, recency, domain-specific aggregates) even when using a deep model, because tabular data rarely has the scale or natural structure that makes pure representation learning dominate the way it does for images or text.

Direct answer. The most plausible causes are that the two connections are actually hitting different underlying data (a lagging or differently-tuned replica), that the replica's statistics are stale relative to the primary's, or that a configuration difference between the two (memory settings, cost parameters) leads the same query to a genuinely different plan; isolate which one by comparing statistics freshness, configuration, and data currency between the two connections directly, rather than assuming the query itself is the variable.

Structured elaboration. Start by confirming the two connections are even hitting the same DATA: replication lag means a replica can be seconds, minutes, or more behind the primary, and while that usually doesn't change PLAN shape by itself, it's worth ruling out as a confounding factor before you go further, since a stale replica muddies any comparison you make. Next, compare statistics freshness on the specific tables involved: if the replica's statistics were refreshed at a different time (or on a different schedule) than the primary's, or if statistics don't replicate identically depending on your engine's replication mechanism, the two connections can genuinely be planning from different information even though the underlying schema and data are notionally "the same." Finally, compare configuration directly: a replica provisioned with different memory settings, different cost-model parameters, or even a different engine version can lead an otherwise-identical query to a genuinely different, and genuinely differently-optimal, plan.

Worked example. A replica whose statistics job runs on a different, less frequent schedule than the primary's is a very plausible explanation on its own: if the primary was recently ANALYZE'd after a data shift but the replica hasn't caught up yet, the replica's optimizer is working from an older picture of the data than the primary's, which can easily produce a different (and worse) plan for the identical query text.

Trade-offs and pitfalls. Resist jumping straight to "the replica's hardware must just be slower," which is possible but is a much less common actual cause than a genuine statistics or configuration difference, and treating it as the default explanation without checking the more likely causes first can send you chasing an infrastructure upgrade that wouldn't have fixed the real problem.