Explain conflict resolution and growth

# How to Answer Effectively (with structured examples) Use STAR/STAR-L (Situation, Task, Action, Result, Lessons). Make trade-offs explicit, quantify outcomes, and show ownership. ## 1) Significant Disagreement — Framework + Example Framework: - Align on the shared goal: restate the North Star metric or business outcome. - Decompose the disagreement into testable assumptions. - Generate options and make a simple trade-off table (speed, risk, cost, impact, reversibility). - Use data/experiments where possible; define guardrails. - Decide and document; if still blocked, escalate with a crisp options memo. Example (abbreviated): - Situation/Task: We planned a wide, time-limited promotion to boost orders before a peak weekend. PM wanted to launch broadly for maximum impact; I was concerned about courier capacity and fulfillment reliability (late ETAs drive cancellations and poor customer experience). - Action: - Reframed the goal from “orders placed” to “orders fulfilled” to include reliability. - Pulled historicals showing cancellations rise sharply when ETA error exceeds 5 minutes. - Proposed options: - A) Broad launch (fastest, highest upside; highest risk to reliability). - B) Delay 2 weeks to build full capacity safeguards (lowest risk; misses promo window). - C) Targeted rollout to low-risk stores and hours with a real-time throttle and a circuit breaker on cancellation rate (balanced). - Built a simple capacity model; set guardrails (max +1 pp cancellations, p95 delivery time not to exceed baseline +3 min). Instrumented a kill switch. - Result: We picked C. Achieved +4.7% gross orders and +2.1% net fulfilled orders over the weekend. Cancellations and p95 delivery time held within guardrails. We upstreamed the throttle/circuit-breaker pattern into the promotions framework. - Lessons: Alignment on the true outcome (fulfilled orders), codify guardrails, and prefer reversible, observable rollouts when uncertainty is high. ## 2) One Big Mistake — Framework + Example Framework: - Own it: state the mistake plainly, no blame. - Detect: monitoring, logs, user reports, or data checks that surfaced the issue. - Remediate: contain blast radius, fix forward or roll back, communicate. - Prevent: process/tooling changes (tests, automation, reviews, runbooks, alerts). Example (abbreviated): - Mistake: During a schema migration, I dropped a frequently used index in production without verifying workload impact. p95 DB latency tripled, causing API timeouts. - Detection: On-call pager fired (DB latency SLO breach). Dashboards showed a step-change in slow queries aligned with the deploy. - Remediation: - Initiated incident, temporarily disabled the feature flag relying on the affected queries. - Recreated the index online and scaled up DB temporarily to handle backlog. - Cleared request queues and verified recovery (p95 back to baseline). - Posted status updates to stakeholders every 15 minutes until resolved. - Prevention: - Added a “safe migrations” checklist and CI gate: query plan diff in staging with prod-like data; load-test hot paths. - Required two-person review for DDL changes; maintenance-window guardrails. - Created automated alerts for index drops/creation and a runbook for DB performance regressions. - Lessons: Production-like validation for schema changes, explicit ownership of operational risk, and fast, transparent incident comms. ## 3) Project Deep Dive — ETA Prediction Service (Representative Example) This is a template for a strong deep dive. Tailor with your actual project specifics. - Goals: - Reduce ETA error to improve conversion and reduce cancellations. - Target: lower mean absolute error (MAE) by 15%, keep p95 service latency < 75 ms, and maintain 99.9% availability. - Business metrics: +0.2–0.5 pp checkout conversion, −5–10% cancellations, −5–10% courier idle time. - System Architecture: - Inference Service (stateless): exposes /eta for real-time predictions. - Online Feature Store: curates fresh features (store prep speed, courier proximity, traffic, time-of-day, weather) with strict TTLs. - Model Serving: gradient-boosted trees with quantile outputs (P50, P90). - Data Sources: order events and courier location via streaming (e.g., Kafka/Kinesis), vendor traffic API, weather feed. - Offline Training Pipeline: daily retraining, feature engineering, backfills, validation, model registry. - Experimentation & Routing: canary, shadow traffic, and A/B assignment with guardrails. - Observability: SLI/SLOs on latency, availability, feature freshness, and calibration drift; red/black dashboards and alerts. - Fallbacks: heuristic ETA (segment-based averages) when dependencies degrade; multi-provider traffic fallback. - Key Decisions and Trade-offs: - Model choice: gradient-boosted trees over deep models for latency/interpretability. Trade-off: slightly lower ceiling vs simplicity and speed. - Quantile regression: return P50 and P90 to better communicate uncertainty; use P90 for user-facing ETA to reduce underestimation risk. - Feature freshness vs cost: caching traffic data for 2–3 minutes reduced QPS to vendors by ~60% with minimal accuracy loss. - Training–serving skew: standardized an offline/online feature DSL to ensure parity; added skew detectors. - Rollout: shadow → 5% canary → 25% → 100% with circuit breakers on cancellations and delivery-time p95. - Risks and Mitigations: - Data quality drift: schema/volume monitors, drop to heuristic mode on anomaly. - Vendor outages: circuit breakers, backoff, cached routes, multi-provider fallback. - Tail latency: warm pools, per-tenant timeouts, and feature fetch parallelism. - Cold starts (new stores): hierarchical backoffs (region/store-type averages) until enough data accrues. - Metrics and Impact: - Offline: MAE, RMSE, calibration error (P50 under/overestimation), segment-level fairness (by region/time). - Example MAE: predictions [25, 30, 45] vs actuals [20, 50, 40] → |5| + |−20| + |5| = 30; MAE = 30/3 = 10 minutes. - Online: conversion (+0.3 pp), cancellations (−6.5%), p95 delivery time (−2.1 minutes), courier idle time (−8%), p95 service latency (45 ms), availability (99.97%). - Lessons Learned: - Data and freshness beat fancier models when latency matters. - Calibrated uncertainty (P50/P90) reduces under-promise/over-deliver issues. - Invest early in feature parity checks and drift alerts to prevent silent regressions. - Always ship with guardrails and reversible paths (kill switches, fallbacks). --- Tips to prepare your own stories: - Quantify impact (both tech SLOs and business outcomes). - Show principled trade-offs (speed vs risk, cost vs accuracy, complexity vs maintainability). - Demonstrate ownership: proactive detection, crisp comms, and durable prevention. - Bring artifacts: a simple options table, a data snapshot, a rollout plan, or an architecture sketch if allowed.