Discuss project pride, conflict, and pivots

## How to Approach Use STAR+ID: - Situation: 1–2 lines of context. - Task: Your objective and role. - Actions: The specific things you did (design, coding, experimentation, coordination). - Result: Quantified impact and what improved. - Impact: Tie to business/user/operational value. - Decisions: Name key trade-offs and why you chose them. Timebox to 2–3 minutes each: 20% Situation/Task, 60% Actions/Decisions, 20% Results/Impact. Metrics cheat sheet for engineers: - Performance: p50/p95/p99 latency, throughput, QPS, tail behavior. - Reliability: error rate, crash rate, availability/SLOs, on-call pages. - Efficiency: cost ($/req), CPU/memory, infra utilization. - Product: conversion, CTR, retention, DAU/MAU uplift, task success rate. --- ## 1) Project You Are Most Proud Of (Sample Answer) Situation/Task - Our notification system had high latency and duplicate sends, hurting engagement. I was the primary backend engineer tasked to design and implement a real-time, reliable delivery service within one quarter. Actions - Designed an event-driven pipeline: producers → Kafka → delivery workers. - Implemented idempotency with dedupe keys in Redis to prevent duplicate sends. - Chose at-least-once delivery with idempotent handlers rather than exactly-once for better availability and simpler failure recovery. - Partitioned topics by user shard using consistent hashing to avoid hot partitions; applied back-pressure and exponential retry with dead-letter queues. - Adopted gRPC with Protobuf for stable, versioned contracts and lower serialization overhead. - Rolled out via feature flags and canaries; instrumented p50/p95 latency, error rate, and cost per million notifications; added circuit breakers and alerting. Decisions/Trade-offs - At-least-once + idempotency vs exactly-once: simplicity and latency favored the former. - Kafka + Redis vs bespoke queue: reduced build/ops risk and accelerated delivery. - gRPC vs REST: prioritized latency and typed contracts over broad client compatibility. Results/Impact - Reduced p95 delivery latency from ~1.1s to ~320ms (≈71% faster). - Error rate dropped from 2.3% to 0.4% (≈5.8× improvement); on-call pages down 80%. - Cost per 1M notifications decreased ~35% by lowering retries and right-sizing instances. - Notification CTR increased 18% due to timely delivery; expanded capacity 3× without incidents. Why this works - Clear role ownership, explicit technical decisions, and quantified impact that maps to user value and operability. Template you can adapt - Situation/Task: Problem + your mandate, timeline. - Actions: Architecture, algorithms, data layout, infra choices, testing/rollout. - Decisions: Trade-offs and rejected alternatives. - Results: Before/after metrics, costs, reliability, product outcomes. --- ## 2) Resolving a Team Conflict (Sample Answer) Situation/Task - A teammate proposed batching writes to raise throughput for our ingestion service. I was concerned this would worsen tail latency and jeopardize our p95 SLO. As the service owner, I needed alignment without blocking progress. Actions - Framed the decision with a short RFC: defined success metrics (throughput, p95 latency, error rate), constraints (SLOs), and options (batching, partial batching, outbox pattern). - Built two 1–2 day spikes: (A) full batching, (B) micro-batching with adaptive batch size and flush-on-timeout. - Ran a canary in production at 5% traffic with guardrails: auto-rollback on p95 > SLO + 10% or error rate > 0.5%. - Facilitated a review with the TL, PM, and SRE; shared real data and risks; captured the decision in the design doc and change log. Decision/Outcome - Adopted micro-batching with a 25ms flush timeout and circuit breaker; preserved p95 latency while improving throughput. - Throughput +40% at p95 within SLO (from 280ms to 290ms target); error rate unchanged. - Documented learnings and added a load test to CI to catch regressions early. Stakeholder handling - Anchored on shared, measurable goals (SLOs, throughput) rather than opinions. - Created a safe path to test ideas with canaries and clear rollback conditions. Why this works - Shows respectful disagreement resolution via data, experimentation, and transparent decision-making. Template - Disagreement: What/why it mattered. - Approach: Framework for decision (RFC, criteria, experiments). - Stakeholders: Who you aligned and how. - Outcome: Decision, metrics, and follow-ups. --- ## 3) Handling a Major Requirement Pivot (Sample Answer) Situation/Task - Mid-sprint, legal/compliance required that our usage analytics avoid sending any raw identifiers off device. We had 5 weeks to ship an MVP for a launch. I owned data ingestion and reporting. Actions - Re-scoped to an MVP: local aggregation on device, upload only aggregated counts with differential privacy noise; deferred user-level funnels to a later phase. - Defined must-have vs nice-to-have with PM and legal; updated a 2-page plan with new scope, risks, and dates. - Changed design: moved from server-side sessionization to on-device rollups, added a local store, and implemented a sync protocol with backoff and integrity checks. - Communicated trade-offs: less granular analytics initially, but compliant and on time. Proposed a follow-up to support cohort analysis via privacy-preserving sketches. - Ensured delivery: feature flag, staged rollout, dashboards for data completeness and privacy budgets; success criteria agreed upfront. Results/Impact - Shipped the compliant MVP in 4 weeks, unblocking the product launch. - Data completeness 98–99% under normal conditions; privacy budget respected; zero compliance issues in audit. - Follow-on phase added cohorting using sketches with acceptable accuracy trade-offs. Why this works - Demonstrates scope management, stakeholder communication, and technical adaptation under constraints. Template - Pivot: What changed and deadline. - Re-scope: MVP, cut list, risk/impact. - Communicate: Trade-offs, owners, dates. - Deliver: Instrumentation, guardrails, rollout plan. - Validate: Metrics and acceptance criteria. --- ## Common Pitfalls and How to Avoid Them - Vague impact: Always quantify (even with ranges/estimates) and state baselines. - "We" without "I": Credit the team but be explicit about your actions and decisions. - Over-index on tech, ignore outcome: Tie decisions to metrics and user/business value. - Neglect guardrails: Mention canaries, SLOs, rollbacks, and monitoring when proposing changes. - Blamey conflict stories: Focus on process/data and what you learned. ## Quick Fill-In Templates - Proud Project: "Owned X to achieve Y in Z weeks. Chose A over B because C. Result: metric1 ↑a%, metric2 ↓b%, reliability/cost improved by d%." - Conflict: "Disagreed on X due to Y. Set criteria Z, ran experiments E with guardrails G. Decision D led to metrics M." - Pivot: "Requirement changed to R under deadline D. Re-scoped to MVP V, cut C, communicated trade-offs T. Delivered with metrics M and validation V." Use these structures to craft your own authentic stories with clear ownership, decisions, and measurable outcomes.