Quantitative Analysis and Metrics Interpretation Questions

Core skills for working with numeric business data: calculating and interpreting key metrics, comparing options numerically, identifying trends and anomalies, performing variance checks, and testing assumptions. Includes reading dashboards and query results, extracting meaningful insights from revenue and operational metrics, segmenting data, identifying outliers, and understanding what metrics indicate about business performance. Candidates should be comfortable stating and justifying assumptions, performing simple break even and cost benefit reasoning, and translating numbers into prioritized actions or follow up analyses. This topic covers cross functional metric types from sales and operations to product and marketing, and emphasizes structured thinking, correct metric definitions, basic descriptive statistics, and how to use data to support recommendations.

MediumTechnical

43 practiced

Explain how to decompose a week-over-week revenue change into the contributions from order volume (number of orders) and average order value (AOV). Provide formulas and outline SQL or pandas steps to compute each component's contribution to the total revenue variance.

Sample Answer

Goal: break total revenue change ΔR = Revenue_w - Revenue_{w-1} into parts from volume (orders count) and price (AOV = revenue/orders).

Formulas- R_t = N_t * A_t (N = orders, A = AOV)- ΔR = R_t - R_{t-1}Decompose using a standard two-factor decomposition (midpoint/average weights) to avoid ordering bias:- Contribution_volume = (N_t - N_{t-1}) * (A_t + A_{t-1}) / 2- Contribution_price = (A_t - A_{t-1}) * (N_t + N_{t-1}) / 2Check: Contribution_volume + Contribution_price = ΔR

Rationale: uses average of the other factor so interaction is split evenly.

SQL steps (aggregate by week):1. Compute per-week aggregates: SELECT week, COUNT(DISTINCT order_id) AS N, SUM(order_value) AS R, SUM(order_value)/COUNT(DISTINCT order_id) AS AOV FROM orders GROUP BY week;2. Self-join prior week: SELECT cur.week, cur.N AS N_t, prev.N AS N_prev, cur.AOV AS A_t, prev.AOV AS A_prev, (cur.N - prev.N) * (cur.AOV + prev.AOV)/2 AS contribution_volume, (cur.AOV - prev.AOV) * (cur.N + prev.N)/2 AS contribution_price, (cur.R - prev.R) AS total_delta FROM weekly cur LEFT JOIN weekly prev ON prev.week = cur.week - 1;

pandas steps:1. weekly = df.groupby('week').agg(N=('order_id','nunique'), R=('order_value','sum')) weekly['AOV'] = weekly['R'] / weekly['N']2. weekly = weekly.sort_index() weekly[['N_prev','A_prev','R_prev']] = weekly[['N','AOV','R']].shift(1)3. weekly['contrib_volume'] = (weekly['N'] - weekly['N_prev']) * (weekly['AOV'] + weekly['A_prev'])/2 weekly['contrib_price'] = (weekly['AOV'] - weekly['A_prev']) * (weekly['N'] + weekly['N_prev'])/2 weekly['delta'] = weekly['R'] - weekly['R_prev']

Edge cases & notes:- Handle zeros: when N_prev or N_t is 0, AOV undefined; treat AOV as 0 or use add-one smoothing depending on business logic.- Missing weeks: ensure contiguous weeks or align by calendar week; interpolation if needed.- If large changes, report both absolute and percent contributions: contribution_pct = contribution / delta (watch division by zero).- For many factors (e.g., conversion, traffic), extend using multiplicative decomposition or log-differences.

EasyTechnical

39 practiced

Implement a Python function detect_outliers(values: List[float]) -> List[int] that returns indices of outliers using the Median Absolute Deviation (MAD) method with threshold = 3. Your implementation should handle small sample sizes and the case where MAD is zero.

Sample Answer

Approach: Compute the median, then the Median Absolute Deviation (MAD). Use the scaled MAD (by 1.4826) to make it consistent with standard deviation for normal data. Flag points as outliers when their modified z-score = |x - median| / (scaled_MAD) > threshold (3). If MAD is zero (or near zero), fall back to using sample standard deviation; if that is also zero, there are no outliers.

python

from typing import List
import math

def detect_outliers(values: List[float], threshold: float = 3.0) -> List[int]:
    """
    Returns indices of outliers using the MAD method (threshold default 3).
    Handles small samples and the case where MAD is zero by falling back to std.
    """
    n = len(values)
    if n == 0:
        return []

    # helper: median
    sorted_vals = sorted(values)
    def median(arr):
        m = len(arr)
        mid = m // 2
        if m % 2:
            return arr[mid]
        return 0.5 * (arr[mid - 1] + arr[mid])

    med = median(sorted_vals)

    # absolute deviations from median
    abs_devs = [abs(x - med) for x in values]
    mad = median(sorted(abs_devs))

    # scale MAD to be consistent estimator for std under normality
    scaled_mad = mad * 1.4826

    # fallback if scaled_mad is zero or extremely small
    if scaled_mad <= 1e-12:
        # compute sample std (population std) around median to keep symmetry
        mean_dev = sum((x - med) ** 2 for x in values) / n
        std = math.sqrt(mean_dev)
        if std <= 1e-12:
            return []  # all values identical
        denom = std
    else:
        denom = scaled_mad

    outlier_indices = [i for i, x in enumerate(values) if abs(x - med) / denom > threshold]
    return outlier_indices

Key points:- MAD is robust to outliers; scaling factor 1.4826 aligns it with standard deviation for normal data.- Fallback to std prevents division-by-zero when data has low variability.- Time complexity: O(n log n) due to sorting (median can be O(n) but sorting is simpler). Space: O(n).Edge cases:- Empty list returns [].- All-identical values return [].- Small n handled by same logic; with n=1 or 2 std/MAD fallback ensures no crash. Alternative: use quickselect for O(n) median if performance-critical.

EasyTechnical

47 practiced

You have a three-step funnel during last month: page_views = 10,000; signups = 500; purchases = 50. Compute step conversion rates (page->signup, signup->purchase, overall). Then discuss whether a 1 percentage-point absolute increase in overall conversion is practically important and whether this sample size is sufficient to detect such a change statistically.

EasyTechnical

44 practiced

A new paid feature costs $50,000 to build and will incur $1 per paying user per month in hosting. Pricing is $10/month per paying user. How many paying users must you acquire per month to break even within 12 months? Show all calculations and assumptions.

MediumSystem Design

41 practiced

Design automated checks and monitoring to ensure a revenue metric is reliable from ingestion to dashboard. Include examples of SQL checks or queries (row counts, null rates, reconciliation totals), threshold rules, alerting cadence, and a plan for triage when an alert fires.

Sample Answer

Requirements and scope:- Ensure daily revenue metric (ETL pipeline → warehouse → BI dashboard) is accurate and trustworthy.- Detect ingestion failures, schema drift, data loss, reconciliation mismatches, and anomalies.

High-level architecture:- Instrumented ETL (Airflow), data warehouse (Redshift/BigQuery), monitoring DB/table, alerting (PagerDuty/Slack/email), and dashboards.

Core automated checks (run after each ETL job and nightly/full-run):1. Ingestion health- Row-count compare (source vs staging)

sql

-- source_count and staging_count are results from respective sources
SELECT
  src.day,
  src.count AS source_count,
  stg.count AS staging_count,
  (stg.count - src.count) AS diff,
  SAFE_DIVIDE(stg.count, src.count) AS ratio
FROM source_counts src JOIN staging_counts stg USING(day);

Threshold: fail if ratio < 0.99 or >1.01.

2. Null-rate & schema checks

sql

SELECT
  'revenue' AS col,
  COUNT(*) AS total_rows,
  SUM(CASE WHEN revenue IS NULL THEN 1 ELSE 0 END) AS nulls,
  SAFE_DIVIDE(SUM(CASE WHEN revenue IS NULL THEN 1 ELSE 0 END), COUNT(*)) AS null_rate
FROM staging.revenue
WHERE day = DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY);

Alert if null_rate > 0.005 (0.5%) or any unexpected column type change.

3. Reconciliation totals (staging → warehouse → dashboard)

sql

SELECT
  SUM(revenue) AS stg_total
FROM staging.revenue WHERE day = '2025-12-04';

SELECT
  SUM(revenue) AS fact_total
FROM analytics.fact_revenue WHERE day = '2025-12-04';

Threshold: absolute difference > $500 or relative > 0.5% triggers high-severity alert.

4. Duplicate / uniqueness checks

sql

SELECT id, COUNT(*) c FROM staging.revenue GROUP BY id HAVING c > 1 LIMIT 10;

Alert on duplicates > 0.

5. Freshness / latency- Check last_ingest_timestamp per source; alert if > 2x expected interval.

6. Statistical anomaly detection (daily revenue vs 7-day rolling mean ± 3σ)

sql

WITH stats AS (
  SELECT
    day,
    SUM(revenue) AS daily_rev,
    AVG(SUM(revenue)) OVER (ORDER BY day ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING) AS mu,
    STDDEV_POP(SUM(revenue)) OVER (ORDER BY day ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING) AS sigma
  FROM staging.revenue
  GROUP BY day
)
SELECT day, daily_rev, mu, sigma
FROM stats
WHERE ABS(daily_rev - mu) > 3*sigma;

Alert as warning; escalate if sustained or paired with reconciliation failure.

Alerting cadence & severity:- Critical (P0): ingestion missing, reconciliation fail, schema change — immediate page (PagerDuty) + Slack + email; require acknowledgement within 15 min.- High (P1): duplicates, high null_rate, large drift — Slack + email, review within 1 hour.- Medium (P2): single-day anomaly without other failures — daily digest for analyst review.- Low (P3): minor threshold drift — weekly report.

Alert content:- Job/run id, timestamps, failing check, SQL snippet, affected rows, links to raw logs and recent historical metrics, run playbook link.

Triage playbook (when alert fires):1. Acknowledge and classify severity.2. Quick sanity checks (last successful run, pipeline logs, system resource alerts).3. Run targeted SQL queries: - Re-run counts with source and staging slices. - Sample raw rows for failed partitions.4. Root-cause hypotheses: - Upstream schema change, late upstream job, code bug, null propagation, duplicate ingestion, partition overlap.5. Fix or mitigate: - Re-run ETL for affected partition, roll back transform, apply hotfix, or mark dashboard as stale (disable auto-update).6. Postmortem: - Document RCA, time-to-detect, time-to-resolve, and add automated guards (tighten thresholds, add tests).7. Continuous improvement: - Track alert noise; adjust thresholds and introduce automated reconciliation jobs or checkpoints.

Operational best practices:- Keep checks idempotent and fast (target < 5 minutes).- Maintain historical metrics & alert history to tune thresholds.- Implement test data and canary runs for schema or logic changes.- Include data owners in on-call rotation for critical business metrics.

This design balances fast detection, prioritized alerts, actionable diagnostics (SQL snippets), and a clear triage workflow to restore trust in the revenue metric.

Unlock Full Question Bank

Get access to hundreds of Quantitative Analysis and Metrics Interpretation interview questions and detailed answers.

Join thousands of developers preparing for their dream job.