Explain resume projects and behavioral responses

Model STAR answer for a Software Engineer (with teaching notes and measurable details) STAR primer (how to structure your story): - Situation: Brief business context and baseline metrics. - Task: Your role, scope, success criteria, constraints. - Actions: Design choices, trade-offs, execution, collaboration, risk/quality management. - Results: Quantified impact, lessons, what you'd do differently. Situation - I led the modernization of a real-time ETA and dispatch service for a two-sided mobility marketplace. The legacy service had accuracy and reliability issues that affected conversion and cancellations. - Baselines (prior 4 weeks): - ETA accuracy: MAE p50 = 3.8 min, p95 = 8.5 min (too optimistic in dense urban cores). - API latency: p95 = 420 ms, p99 = 900 ms. - Reliability: ~3 customer-facing incidents/week; 99.5% weekly availability. - Business: rider cancellation rate = 11.2% (higher when ETA error > 5 min), driver acceptance = 82%. - Constraints: 3-month deadline ahead of peak season; zero-downtime cutover; backward-compatible API; keep infra cost flat. Task - As the tech lead and primary IC, I owned architecture, delivery plan, quality gates, and cross-team coordination (Data Platform, Mobile, SRE). Success meant: p95 latency < 250 ms, ETA MAE p50 < 3.0 min, 99.95% availability, and reduced cancellation rate (>5% relative reduction) without increasing infra cost. Actions Architecture and system design - Extracted ETA/dispatch into its own service with clear SLAs. Introduced: - Event-driven ingestion (Kafka) for telemetry; idempotent consumers with schema evolution (Protobuf + schema registry). - A small online feature store (Redis + CDC from the offline store) to align offline/online features and reduce training/serving skew. - gRPC for low-latency, typed contracts between services; REST kept for public API via an edge proxy. - Caching/approximation: short-lived geo-tile caches; approximate nearest neighbor (HNSW) for candidate drivers to cut cold latency. - Traffic controls: shadow reads, 5%-25%-50%-100% canary rollout; circuit breakers and load-shedding for tail protection. Modeling and accuracy - Moved from a linear model to a gradient-boosted tree (XGBoost) with features like road class, time-of-day, incident density, dynamic supply/demand ratio; per-city calibration layer (isotonic regression) to reduce geographic bias. - Retraining cadence daily; drift detection via PSI (population stability index) and triggered retrain if PSI > 0.2. - Cold-start fallback: fast path using historical medians by geo tile and time bucket to avoid unbounded tail latency. Reliability and SLOs - Defined SLOs: 99.95% availability; latency targets p95 < 250 ms, p99 < 400 ms with an error budget policy. Implemented autoscaling (HPA on CPU and RPS), and graceful degradation (fallback model if feature store misses exceed 2%). - Observability: RED metrics (rate, errors, duration), golden signals, tracing (OpenTelemetry), and per-market dashboards. Cross-team collaboration and disagreements - Disagreement 1: gRPC vs REST between services. Concern: tooling and learning curve for gRPC. Resolution: RFC with benchmarks showed ~25% latency improvement and strong typing; decision: gRPC internally, REST at the edge; we wrote onboarding docs and codegen templates. - Disagreement 2: Single global model vs per-market models. Product wanted speed; DS preferred per-market accuracy. We phased it: start with a global model + calibration, then split high-volume markets once we validated lift. ADR documented the trade-off. - Dependency management: created a RACI and weekly 30-min cross-team sync; tracked risks (schema ownership, backfill windows, mobile release timing) in a shared risk register with clear DRI per risk. Quality under time pressure - Testing pyramid: unit tests, property-based tests for geospatial math, contract tests (Protobuf schemas), load tests (p50/p95/p99 latency), chaos drills for dependency failures, and shadow-traffic validation. - Release strategy: feature flags, canary, automatic rollback on SLO burn; data-quality checks (missingness, distribution drift) as CI gates. Results (measured impact) - Accuracy: ETA MAE p50 from 3.8 → 2.9 min (−24%), p95 from 8.5 → 6.4 (−25%). - Latency: API p95 from 420 → 230 ms (−45%); p99 from 900 → 380 ms (−58%). - Reliability: incidents down from ~3/week → 0.3/week; availability to 99.97%. - Business: rider cancellation −7.1% relative; driver acceptance +3.2 pp; overall weekly trips +1.4%; cost −18% via instance right-sizing and cache hit improvements. - Delivery: hit the peak-season readiness date; zero-downtime cutover with 3 staged rollouts. Hardest challenge - Technical: Training/serving skew and real-time data quality. Shadow validation uncovered late/duplicate events causing biased features. Fix: added event-time watermarks, dedupe keys, and feature backfill windows; promoted a feature-contract checklist and offline/online parity tests. Organizational: balancing scope with deadline—kept a must/should/could backlog with explicit descopes tied to SLOs. Trade-offs made - Accuracy vs latency: limited model depth and feature set on hot path; complex features computed asynchronously and used only when available within 50 ms budget. - Global vs per-market models: phased approach to meet timeline, then specialized where ROI was clear. - Consistency vs availability: chose eventual consistency for non-critical counters to protect tail latency. Failure/missed deadline example - I missed an internal milestone for a historical backfill that fed the calibration layer by 1 week. Root causes: underestimated the time to re-index with PII redaction and the downstream re-materialization lag; we also lacked a dry-run environment with realistic volumes. - What I did: - Ran a blameless postmortem; created a backfill playbook (quota-aware throttling, chunked backfills, checkpointing, and roll-forward strategy). - Added a stage gate: no production backfill without a 10% volume rehearsal and on-call coverage. - Adjusted planning to include data-platform wait times and privacy reviews in critical path. - What I’d change: earlier capacity test with production-like data and a tighter integration with the privacy team; enforce backfill SLOs with owners. How success was measured and communicated - KPIs: - ETA accuracy: MAE = mean(|ETA_pred − ETA_actual|); tracked p50/p90/p95 by market. - System: p95/p99 latency, availability, error rate. - Business: cancellation rate, driver acceptance, trip conversion, and cost per 1k requests. - Experimentation: A/B holdouts with guardrails (no market sees >1% degradation in tail latency or cancellation). Pre-registered success criteria. - Communication: weekly stakeholder updates (RAG status, risks, mitigations), live dashboards, and demo videos; incident reports within 24 hours if SLOs breached. Leadership, ownership, conflict resolution, adaptability - Leadership: set vision, broke scope into workstreams, mentored two junior engineers, and established coding standards and ADR templates. - Ownership: on-call during rollout, wrote operational runbooks, and led the post-launch hardening sprint. - Conflict resolution: used data (benchmarks/experiments) and ADRs to converge; kept decisions reversible where possible. - Adaptability: when mobile release slipped, we added a compatibility shim to support both old/new clients during the transition. Notes you can reuse to tailor your own story - Quantify baselines and final impact; define success criteria upfront. - Show one hard technical challenge and one organizational challenge. - Surface trade-offs explicitly and why your choice was right for constraints. - Include one honest failure with concrete process changes. - Show how you measured, communicated, and ensured quality under pressure.