Metrics, Guardrails, and Evaluation Criteria Questions
Design appropriate success metrics for experiments. Understand primary metrics, secondary metrics, and guardrail metrics. Know how to choose metrics that align with business goals while avoiding unintended consequences.
MediumTechnical
73 practiced
You have conflicting signals: the primary metric is statistically unchanged but several secondary metrics degrade (e.g., session length, engagement). Construct a decision framework to determine whether to roll out, hold, or rollback. Include tolerances, time windows for observation, stakeholder signoff process, and a phased rollout plan if appropriate.
Sample Answer
Decision framework (Data Scientist perspective)1) Clarify metrics and hypotheses- Primary metric (M0) defined and powered for experiment.- List secondary metrics (M1...Mn) with directionality (improve/degrade) and business impact ranking.2) Statistical/operational tolerances- Primary: require no statistically significant negative effect at α=0.05 and pre-specified minimum detectable effect (MDE).- Secondaries: set soft/ hard thresholds. Soft: <5% relative change tolerated; Hard: >10% relative drop OR p-value <0.01 → triggers action.- Minimum sample/time: retain original power assumptions (e.g., ≥80% power; at least one full business cycle + 7 days).3) Observation windows & monitoring cadence- Immediate: real-time dashboards (minutely/hourly) for safety signals for critical metrics (errors, crash rate, payments).- Short-term: daily aggregated checks for 1–2 weeks (or until sample size reached).- Medium-term: weekly cohort analysis over 4 weeks for retention/engagement trends.4) Decision rules- Rollout: M0 unchanged or improved AND all secondaries within soft thresholds after full short-term window.- Hold/Investigate: M0 unchanged but one or more secondaries breach soft threshold but below hard. Trigger root-cause analysis (segmentation, funnel, instrumentation); pause further rollout until resolved.- Rollback: Any hard-threshold breach OR systemic quality issues (errors, regulatory).5) Phased rollout plan- Canary → 1% users for 24–72h; if pass safety signals, expand to 5% for 3–7d; then 20% for 7–14d; then 100%.- At each phase require passing checklists: sample size, health metrics, secondaries within soft thresholds.6) Root cause analysis steps when signals conflict- Segment by device, geography, traffic source, user cohort.- Inspect instrumentation, telemetry, and qualitative feedback.- Run A/A sanity or re-randomize if imbalance suspected.- Fit causal / regression models controlling for covariates to test robustness.7) Stakeholder signoff process- Required signers: Data Science (statistical validity), PM (business impact), Engineering (stability), Product Ops/Support (user impact), Legal/Compliance if relevant.- Signoff checklist: confirm sample/power, dashboard green, no hard breaches, RCA if soft breaches with mitigation plan, rollout next phase decision.- Escalation timeline: if unresolved in 48–72h, executive review and decide rollback vs. extended hold.8) Communication & postmortem- Communicate decision, rationale, and timeline to stakeholders and customer-facing teams.- If rolled out, continue monitoring cohorts for 90 days and schedule a postmortem with learnings and next steps.This framework balances statistical rigor, operational safety, and business context; thresholds and windows should be tuned to product risk and traffic volume.
EasyBehavioral
78 practiced
Tell me about a time you uncovered a metric discrepancy between two reports (e.g., dashboard A vs. warehouse query). How did you investigate the root cause, communicate the impact to stakeholders, and implement measures to prevent recurrence? Use STAR format and be specific about diagnostic steps.
Sample Answer
Situation: At my previous company I was running weekly churn-analysis reports. Two sources showed different active-user counts for the same 7-day window: Tableau dashboard A (product analytics) reported 42,300 active users while our warehouse SQL query used for modeling returned 39,800. That ~6% gap would change churn rates and revenue forecasts.Task: I needed to find the root cause quickly, quantify business impact, communicate clearly to stakeholders, and fix the pipeline to prevent recurrence.Action:- Reproduced the discrepancy: reran both queries and exported results to CSV to eliminate visualization caching. Confirmed difference persisted.- Scoped difference by slicing: compared counts by day, platform, and region to see where divergence began. Found the gap existed only on mobile for two recent days.- Checked definitions: validated "active user" definition in Tableau (event-based: first session event) vs. warehouse (distinct user_id in sessions table with session_start between timestamps). Discovered Tableau dashboard used event table where a new mobile SDK change duplicated session_start events for some users.- Investigated lineage and timing: reviewed ETL job logs and mobile release notes. Found an SDK change caused duplicate session events that Tableau’s live connector aggregated without deduplication; warehouse ETL included dedup step so it filtered them.- Quantified impact: computed that duplicated events inflated active mobile users by ~2,500, changing weekly churn estimate by 0.4 percentage points and estimated revenue forecast by ~$120k/month.- Communicated to stakeholders: emailed a concise summary to Product, Analytics Manager, and Engineering with (1) what I found, (2) business impact (numbers), (3) immediate mitigation (mark Tableau dashboard as stale and add dashboard note), and (4) remediation plan and timeline.- Remediation: worked with mobile engineers to revert SDK behavior and with analytics engineers to add deduplication in the live Tableau pipeline and a reconciliation job comparing dashboard vs. warehouse daily counts.- Prevent recurrence: created automated daily reconciliation monitoring (scheduled SQL job + Slack alert when variance >2%), documented the canonical definition of "active user" in the analytics wiki, and added a checklist item to release process to flag event-schema changes.Result: Within 72 hours the dashboard was corrected and mobile SDK fix rolled out; discrepancy dropped below 1%. Stakeholders regained confidence; the reconciliation alerts caught a smaller schema issue two months later before it affected KPIs. I learned to prioritize clear metric definitions and automated reconciliation between reporting layers.
MediumTechnical
66 practiced
Implement a Python function to compute the average treatment effect (ATE) and a 95% bootstrap confidence interval for a binary outcome. Signature: def compute_ate_with_bootstrap(treatment: np.ndarray, outcome: np.ndarray, n_bootstrap: int = 1000) -> Tuple[float, float, float]. Assume treatment is 0/1 and arrays are same length. Return (ate, ci_lower, ci_upper). Write clear, efficient code and mention assumptions about independence.
Sample Answer
To compute the Average Treatment Effect (ATE) for a binary treatment and derive a 95% bootstrap confidence interval, we can: (1) compute the sample difference in means (treated - control) as the ATE estimate, (2) repeatedly resample observations with replacement (resampling rows preserves joint distribution of treatment and outcome under IID sampling), recompute ATE for each bootstrap sample, and (3) take the 2.5th and 97.5th percentiles of the bootstrap ATE distribution.Key points and assumptions:- We assume independent, identically distributed units and that resampling rows is valid; bootstrap estimates sampling variability of the ATE under IID sampling.- We do NOT adjust for confounding — the estimate is causal only if treatment assignment is unconfounded (e.g., randomized or conditional ignorability holds).- Time complexity: O(n_bootstrap * n). Space: O(n_bootstrap) for storing bootstrap ATEs.- Edge cases handled: mismatched lengths, non-binary treatment, no treated/control, empty input.- Alternatives: stratified bootstrap (resample within treatment groups) if you want to preserve treatment group sizes; bias-corrected/bootstrap-t intervals if you need better coverage.
python
import numpy as np
from typing import Tuple
def compute_ate_with_bootstrap(treatment: np.ndarray,
outcome: np.ndarray,
n_bootstrap: int = 1000,
random_state: int = None) -> Tuple[float, float, float]:
"""
Returns (ate, ci_lower, ci_upper) where ate is E[Y|T=1]-E[Y|T=0]
and ci_* are the 95% bootstrap percentile interval bounds.
Assumes treatment is 0/1 and treatment/outcome are same length.
"""
if treatment.shape[0] != outcome.shape[0]:
raise ValueError("treatment and outcome must have same length")
n = treatment.shape[0]
if n == 0:
raise ValueError("Empty inputs")
if not np.isin(treatment, [0, 1]).all():
raise ValueError("treatment must be binary 0/1")
rng = np.random.default_rng(random_state)
treated_mask = treatment == 1
control_mask = ~treated_mask
if treated_mask.sum() == 0 or control_mask.sum() == 0:
raise ValueError("Need at least one treated and one control unit")
def ate_from_arrays(t, y):
# difference in means (handles binary or continuous y)
return y[t == 1].mean() - y[t == 0].mean()
ate = ate_from_arrays(treatment, outcome)
boot_ates = np.empty(n_bootstrap)
indices = np.arange(n)
for i in range(n_bootstrap):
samp_idx = rng.choice(indices, size=n, replace=True)
boot_ates[i] = ate_from_arrays(treatment[samp_idx], outcome[samp_idx])
ci_lower, ci_upper = np.percentile(boot_ates, [2.5, 97.5])
return float(ate), float(ci_lower), float(ci_upper)EasyBehavioral
72 practiced
Tell me about a time you defined success metrics and guardrails for a cross-functional product launch. Use the STAR structure: describe the situation, your task, actions you took to align stakeholders and instrument metrics, and the measurable result. Emphasize how you handled trade-offs and disagreements.
Sample Answer
Situation: At my previous company we launched a recommendation feature for our mobile app to increase trial-to-paid conversions. The project involved product, engineering, design, and growth teams and a fixed Q3 deadline.Task: As the data scientist on the cross-functional team, I was responsible for defining success metrics and guardrails, instrumenting tracking, and resolving stakeholder disagreements about priorities.Action:- Aligned stakeholders by running a 1-hour kickoff to agree on primary OKR: increase trial-to-paid conversion rate. I proposed primary and secondary metrics: - Primary: 7-day trial-to-paid conversion rate (customer-level) - Secondary: click-through rate (CTR) of recommendations, retention at 30 days, average revenue per user (ARPU)- Defined guardrails to prevent negative outcomes: no more than 5% relative drop in retention, no significant increase in support tickets (p-value < 0.05), and latency impact under 100ms.- Instrumented metrics with product and backend engineers: added user-level event IDs, recommendation exposure, and attribution tags; built a validation suite in Python to sanity-check events and a dashboard in Tableau for weekly tracking.- Handled trade-offs by facilitating a decision matrix: product wanted aggressive personalization to boost CTR; engineering warned about latency and rollout risk. I proposed a phased A/B test: conservative model (phase 1) vs. aggressive model (phase 2), with canary traffic at 10% and automatic rollback if guardrails violated.- To resolve disagreement, I used data simulations from historical logs to show likely latency and conversion trade-offs and agreed on thresholds that balanced impact and risk.Result: The phased launch increased 7-day conversion by 12% (statistically significant, p<0.01) with no measurable retention drop (0.8% relative change) and latency stayed within limits. The guardrail-driven rollback for phase 2 prevented deploying an aggressive model that would have increased support tickets by an estimated 18%. Stakeholders reported higher trust in metrics and we adopted the same metric/guardrail template for future launches.
HardTechnical
105 practiced
List guardrail metrics and an alerting/response strategy for ML models in production to detect concept drift, data drift, label delay, and feedback loops. For each guardrail define how to measure it (statistical test or metric), suggested thresholds, and an automated remediation (alert, throttle, rollback, retrain).
Sample Answer
Below is a practical set of guardrails for production ML addressing concept drift, data drift, label delay, and feedback loops, with how to measure each, suggested thresholds, and automated remediation steps. Also includes a tiered alerting/response strategy.1) Data drift (input feature distribution changes)- Measure: For numeric features use Kolmogorov–Smirnov (KS) test and Population Stability Index (PSI); for categorical use Chi-square or Jensen-Shannon divergence.- Thresholds: PSI > 0.2 (moderate), >0.3 (severe); KS p-value < 0.01 or JSD > 0.1.- Automated remediation: - Tier-1 (warning): Send alert, raise sampling for new-data labeling, enable feature-level logging. - Tier-2 (severe): Throttle non-critical predictions, route to “safe” fallback model or business rules, enqueue retraining job with recent batch.2) Concept drift (model performance change vs same labels)- Measure: Rolling performance metrics (AUC, accuracy, F1) on recent labeled data; concept-drift detectors like ADWIN or Page-Hinkley on prediction residuals.- Thresholds: Relative drop in primary metric > 5% absolute or >10% relative over rolling window (30k predictions or 7 days); ADWIN change detected with confidence 0.01.- Automated remediation: - Immediate alert to SRE/DS. - Canary rollback to previous stable model if drop persists for N batches (e.g., 3 windows). - Trigger expedited retrain with recent data and automated model validation pipeline.3) Label delay / label quality issues- Measure: Label latency distribution (time from prediction to label arrival), fraction of missing/late labels, mismatch between proxy-label metrics and eventual ground truth; monitor decrease in labeled coverage.- Thresholds: Median label latency > expected SLA (domain-specific); labeled coverage < 70% of predictions in monitoring window.- Automated remediation: - Alert product/ops to data-pipeline issue. - Use offline surrogate metrics (weak labels, heuristics, or model-based pseudo-labeling) with lower trust; annotate model outputs as low-confidence. - Pause automated retraining until label backlog resolved; if backlog > threshold, retrain using only high-quality recent labels or conservative sampling.4) Feedback loops / self-reinforcing bias- Measure: Distribution shift conditional on model action (P(feature|model_decision)), uplift drift, increase in population of high-score users, increase in repeated predictions for same entities; causal diagnostics like do-calculus proxies or A/B test outcomes.- Thresholds: Significant divergence (e.g., JS divergence >0.1) between treated and untreated cohorts over time, sustained increase in outcome rates in treated group unexplained by external controls.- Automated remediation: - Alert to Product & DS for investigation. - Turn on randomized exploration (epsilon-greedy), reduce deterministic treatment (throttle), add guardrail rule to prevent repeated high-impact actions. - Launch controlled retrain with de-biased sampling and, if available, counterfactual correction or causal modeling.Tiered alerting/response strategy (automated workflow)- Monitoring agents evaluate guardrails continuously and assign severity (info/warn/critical).- Info/warn: create ticket, notify DS Slack channel, enable increased data capture and shadow mode (serve model but do not act).- Critical: automated mitigation—switch to fallback model or business-rule policy, throttle/flag risky predictions, trigger automated retrain/canary deployment pipeline.- Human-in-the-loop: require DS sign-off before permanent rollback or promotion of new model; store audit trail and metrics; run post-mortem and update thresholds.Operational best practices- Use rolling windows (time-based and count-based) and bootstrapped confidence intervals to avoid noisy alerts.- Maintain a labeled validation stream (canary labeling) and shadow deploy new models to compare performance before promotion.- Automate end-to-end retrain pipelines with unit tests, data checks, and validation gates (performance, fairness, business SLOs).- Log feature provenance, model versioning, and decision metadata for causal analysis and remediation audits.This suite balances statistical detection, conservative automated actions (throttle/rollback/fallback), and human review for irreversible changes.
Unlock Full Question Bank
Get access to hundreds of Metrics, Guardrails, and Evaluation Criteria interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.