Data and Trend Analysis with Pattern Recognition Questions

Analyzing quantitative and qualitative data to identify patterns, trends, correlations, and meaningful insights. Skills assessed include descriptive statistics, time series and trend analysis, visualization and dashboarding, hypothesis generation and testing, identifying seasonality and structural changes, distinguishing signal from noise, and synthesizing findings into clear recommendations. For qualitative inputs candidates should demonstrate coding, theme extraction, categorization, and synthesis of transcripts or survey responses. Emphasis is on choosing appropriate methods, validating patterns, avoiding common pitfalls such as confounding and spurious correlation, and communicating insights effectively to stakeholders.

HardTechnical

16 practiced

Given a daily active users time series with missing days and visible outliers, outline in pseudocode or stepwise form how you would clean the data, impute missing values, detect and optionally remove anomalies, decompose trend/seasonality, and produce a 30-day forecast using a modern tool (e.g., Prophet or ARIMA). Focus on method choices and trade-offs rather than code details.

Sample Answer

1) Clarify objectives & constraints- Forecast horizon = 30 days; acceptable error bands; whether anomalies should be corrected or preserved for business decisions (e.g., outages vs marketing spikes).

2) Data ingestion & validation- Ensure daily index, timezone normalization, deduplicate, check for metadata (campaigns, releases, outages).- Pseudocode: - df = read() - df.date = to_date(df.date); df = group_by_date(sum(DAU))

3) Missing days detection & imputation strategy- Distinguish short gaps (1–3 days) vs long gaps (>7 days) and gaps at edges.- Methods: - Short gaps: linear or seasonal interpolation (roll median or spline). - Long gaps: model-based imputation (Kalman smoothing, SARIMAX, or use Prophet fit to surrounding data and predict missing block).- Trade-off: simple interpolation preserves local shape but underestimates uncertainty; model-based yields better seasonal context but can overfit.

4) Outlier detection & handling- Detect with multiple methods: rolling-median residuals, IQR on residuals, or robust z-score; correlate with external logs (campaigns/releases) to label known events.- Decision: flag anomalies first. For forecasting, either: - Replace anomalies with model-imputed values (if anomaly is noise/outage), - Or keep them and add binary event regressors (if anomaly is meaningful).- Trade-off: removing spikes can improve average forecast but hide real business signals.

5) Decompose trend/seasonality- Use STL (robust) or Prophet’s internal decomposition to extract trend, weekly/day-of-week seasonality, and residuals.- Check stationarity and relative strength of components.

6) Model selection & 30-day forecast- Candidate models: Prophet (good for business features, holiday regressors, changepoints), SARIMA/SARIMAX (if strong AR structure), or ETS/NNAR for complex nonlinearity.- For Prophet: - Add regressors: events, campaigns, promo flags, and holiday/calendar effects. - Tune changepoint_prior_scale (flexibility) and seasonality_prior_scale (smoothness). - Fit on cleaned series; forecast 30 days with simulated uncertainty.- Cross-validate with rolling-origin (backtest) and compute MAE, RMSE, MAPE.

7) Validation & deployment- Validate residuals, coverage of prediction intervals, and business-readability.- Automate pipeline: ingestion → cleaning/imputation → anomaly flagging → model training → forecast + explanation (trend/seasonality + events).- Monitor drift and retrain cadence.

Summary of trade-offs: prefer conservative imputation and flagging to preserve business signals; choose Prophet for product-facing forecasts because it’s interpretable and handles holidays/regressors, but validate against SARIMAX/ensemble for robustness.

MediumTechnical

22 practiced

Design an actionable dashboard to monitor the onboarding funnel for new users. Specify KPIs, visualizations, filters, drill-downs, alert rules, and suggested runbooks so product managers can quickly identify friction points and prioritize fixes.

Sample Answer

High-level goal: give PMs an at-a-glance, actionable view of where new users stall during onboarding, why, and what to do — so fixes are prioritized by impact.

KPIs (show both absolute and rate)- Acquisition → Activation funnel: Visitors, Sign-ups, Email Confirmed, First Key Action (e.g., completed profile), First Success (e.g., created project). Show counts + step-to-step conversion %- Time-to-activation: median & 90th percentile time between Sign-up → First Key Action- Drop-off rate per step and cumulative leak- Success rate by cohort (day/week), retention at D1/D7/D30- Error rates / form validation failures, crash rate during onboarding- Support volume & NPS/CSAT for new users- Acquisition channel LTV proxy (activation % × retention)

Visualizations (dashboard layout)- Top-left: Funnel chart with conversion % annotated and absolute counts- Top-right: Time-series of daily conversion rate and time-to-activation (line + moving avg)- Middle: Bar chart of drop-off by step (absolute drop and %)- Bottom-left: Segmentation heatmap (device × browser, or channel × country) showing activation %- Bottom-right: Table of session replay / top error logs / most common validation errors, with “view replay” links- Side pane: Cohort selector view (D1/D7 retention) and impact-estimate widget (users affected × % drop => potential activations recovered)

Filters & segments- Date range, cohort window, acquisition channel, marketing campaign, country/region, device & OS, browser, user plan (free/paid), traffic source (paid vs organic), experiment flag

Drill-downs- Click a funnel step → list of affected users with attributes, top events, and session replay links- Click a segment in heatmap → time-series and top failing flows for that segment- Click an error → trace to release/commit, recent deploys, percentage of sessions affected

Alert rules (examples, actionable)- Conversion drop: if step-to-step conversion drops >15% vs 7‑day moving avg or >5 percentage points absolute → Alert (Slack + email)- Time-to-activation spike: median increases >50% vs baseline → Alert- Error/crash spike: error rate >0.5% of new-user sessions or 3x baseline → Pager to on-call engineer- Support surge: tickets from new users up >50% day-over-day → PM + Support notification

Suggested runbooks (triage + remediation)1. Triage (PM/Analytics, 15–30 min) - Validate metric (exclude tracking gaps): check analytics event counts, recent deploys/feature flags, data pipeline health - Reproduce: PM or engineer reproduce flow on same device/region; use session replay examples2. Contain (30–120 min) - If blocking error/bug: create high-priority bug ticket, rollback feature flag or release if an immediate fix is needed - If UX confusion: add in-product tooltip or highlight (quick frontend tweak) behind flag3. Diagnose (1–3 days) - Deep dive A/B or cohort analysis to confirm root cause (UX, performance, incorrect copy) - Run usability test or short survey to caught users4. Fix & Validate (days–weeks) - Implement fix, run canary, enable gradual rollout, monitor funnel metrics - Postmortem: quantify recovery and update playbook5. Prioritization framework - Estimate potential recovered daily activations = users affected × typical conversion uplift - Rank fixes by Impact (recovered activations) × Confidence / Effort

Notes for PMs- Always check tracking/instrumentation before escalating.- Tie alerts to runbooks and owners; include remediation SLAs.- Use experiments to validate fixes; track uplift on cohorts.

HardTechnical

16 practiced

After a backend deployment, daily revenue shows a structural change. Describe statistical methods to detect change points while controlling for seasonality, promotions, and other confounders. Explain how you'd attribute the change to the deployment versus external factors and the practical triage steps (e.g., rollback thresholds, runbook actions).

Sample Answer

Approach summary: treat revenue as a time series with known seasonality/promotions, detect structural changes robustly, then attribute by controlling for confounders and running rapid triage.

Detection methods- Preprocess: backfill missing, encode calendar features (weekday, holiday), promotion/marketing flags, user cohort sizes.- Decompose or model seasonality/trend: STL decomposition or a seasonal model (SARIMAX / Prophet) that accepts regressors (promotions, price changes).- Change-point detection: - Offline: Bayesian change point models (e.g., ruptures library, PELT) on residuals after removing seasonality/regressors. - Online/monitoring: CUSUM or EWMA on residuals for rapid alerts; Bayesian Online Changepoint Detection for probabilistic alerts.- Causal attribution: use Interrupted Time Series (ITS) / segmented regression with covariates or Bayesian Structural Time Series (BSTS) / CausalImpact to estimate counterfactual revenue absent the deployment. Include promotion, traffic, cohort, ad spend as regressors.

How to attribute to deployment vs external factors- Control for observed confounders in model (promotions, traffic, price, holiday dummies). If effect persists in residuals after controlling, suspect deployment.- Use synthetic controls: build a weighted combination of unaffected products/regions as counterfactual.- Cohort and funnel checks: did conversion/drop happen in specific browsers, versions, geos, or user cohorts exposed to the deployment? If only deployed subset affected, that implicates the release.- Instrumentation/logs: correlate errors, latency, feature-flag exposures with timing and affected cohorts.- Sensitivity checks: rerun models excluding promotion windows, run placebo tests (pretend deployment at earlier dates) to check false positives.

Practical triage & runbook actions- Alerting thresholds (example): revenue deviation >5% vs modeled counterfactual, sustained >48 hours OR p-value <0.01 from ITS; or residuals >3σ for 24h. Tune to business tolerance.- Immediate steps: 1. Convene incident lead (PM), engineering, analytics, and ops. 2. Pull diagnostics: traffic, errors, latency, DB KPIs, A/B exposures, and promotion schedules. 3. Quick segmentation: by version/flag, geo, device to localize cause. 4. If evidence points to release (e.g., affected cohort = deployed flag users), toggle feature flag or rollback per policy. 5. If inconclusive, escalate to mitigations (rate-limit, rollback to canary, patch), communicate to stakeholders with “what we know/next steps.”- Rollback policy example: immediate rollback if revenue impact >8% and root-cause trace to release; conditional rollback (feature-flag off) if isolated to small cohort; otherwise hotfix if narrow code path.- Post-incident: postmortem, update runbook, add instrumentation, and update statistical detection thresholds.

What I’d deliver as PM- Clear SLA-based thresholds and runbook, dashboard with modeled counterfactual and residuals, and a postmortem with corrective actions (telemetry, tests, rollout strategy changes).

HardTechnical

19 practiced

Case study: You're launching internationally across 10 countries. Create an analytics and experimentation plan to detect regional adoption trends, run localized A/B tests for translations, account for timezone and currency differences, ensure GDPR compliance, and define metrics and dashboards to compare regions fairly. Outline rollout and sampling strategy.

Sample Answer

Requirements & constraints:- Detect regional adoption trends across 10 countries, run localized A/B tests (translations), handle timezones/currencies, GDPR compliance, fair cross-region comparison, rollout & sampling strategy.

Analytics & instrumentation:- Events: standardized schema (user_id*, anon_id, country, region, timezone, currency, locale, event_name, event_props, timestamp_utc). Tag experiments, exposure_time, variant, translation_key.- Capture consent flags and provenance (consent_given, consent_timestamp) to honor GDPR; do not collect PII without consent.- Store timestamps in UTC and also record local_timestamp and timezone offset for cohorting.

Experimentation plan:- Localized A/B tests per country with translation variants (control vs translated copy vs culturally adapted copy).- Use stratified randomization by country and device; ensure random assignment at user-id level (or anon_id) and persist variant.- Minimum detectable effect and power calculations per country; where small sample, run pooled hierarchical models (Bayesian/partial pooling) to borrow strength while allowing country-level estimates.- Pre-register primary metric and statistical method; use sequential testing with alpha-spending to control false positives.

GDPR & privacy:- Implement consent management platform; only activate analytics/experimentation for consenting users in GDPR regions.- Anonymize or pseudonymize identifiers; retention policies and right-to-erasure workflows.- Data processing agreements for vendors and EU data residency if required.

Timezone & currency handling:- Convert revenue metrics to USD using rolling FX rates; report both local-currency and normalized USD. Timestamp normalization for daily/weekly windows using users’ local_date to avoid cutoffs.

Metrics & dashboards:- Primary metrics: active users (DAU/WAU), conversion rate (country-specific funnel), revenue per user (ARPU local + normalized), retention (D1, D7, D30).- Secondary: time-to-first-action, error rates, localization NPS.- Dashboards: per-country and compare view with normalized metrics, sample-size, confidence intervals, experiment status, and pre-specified guardrails (e.g., error spike).- Use segment filters (country, locale, device, consent) and show both pooled and country-level effects.

Rollout & sampling:- Staged rollout: pilot in 1–2 representative countries (high traffic + different language families), validate instrumentation and cultural fit, then ramp to regional clusters (e.g., Western Europe, LATAM).- Sampling: for global experiments, stratified sampling to ensure minimum N per country; for country-specific experiments, allocate 100% within-country traffic but throttle exposed proportion if riskier.- Monitoring: real-time health metrics, kill-switch, and automated alerts for negative impact on core KPIs.

Governance & process:- Pre-mortem and experiment spec template (hypothesis, metrics, ramp plan, kill criteria).- Weekly experiment review with analytics, legal, localization, and engineering.- Use hierarchical analysis and A/B test registry to avoid overlap and interference.

This plan balances local sensitivity, statistical rigor, privacy, and operational safety to detect adoption trends and run fair, effective localized experiments.

MediumTechnical

17 practiced

Explain the difference between correlation and causation using product examples (for example, users who open onboarding emails convert more). For each example propose at least two methods to test for causality using experiments or observational techniques, and mention key assumptions for each method.

Unlock Full Question Bank

Get access to hundreds of Data and Trend Analysis with Pattern Recognition interview questions and detailed answers.

Join thousands of developers preparing for their dream job.