Handle feedback, conflict, and missed metrics

# How to Answer Effectively Use concise, structured storytelling (e.g., STAR: Situation, Task, Action, Result) and show ownership, empathy, data-driven thinking, and follow-through. Below are frameworks and a compact example for each prompt. ## 1) Giving Critical Feedback Framework (SBI + STAR): - Prepare: Identify the specific behavior and impact; gather 1–2 concrete examples. - Permission + Private Setting: Ask for time; keep it 1:1 and timely. - SBI (Situation–Behavior–Impact): - Situation: When/where it happened. - Behavior: Observable, non-judgmental facts. - Impact: Effect on users, team, or goals. - Collaborate on Next Steps: Ask for their perspective, co-create actions and checkpoints. - Follow-up: Reinforce progress; document agreements. Mini Example (STAR): - Situation: A teammate’s PRs frequently bypassed perf benchmarks, causing p95 latency spikes post-release. - Task: Maintain performance SLAs while keeping delivery on schedule. - Action: Held a private 1:1; used SBI: “Last sprint, PRs #4821 and #4840 merged without running the perf suite (behavior) which led to a 12% p95 regression and two hotfixes (impact).” Asked for context, agreed on: (a) PR template requiring perf checkmarks, (b) adding a CI gate for perf, (c) pairing on first run. - Result: Next two sprints had 0 perf regressions; teammate felt supported, not criticized; we kept delivery velocity and codified the checklist in our CONTRIBUTING.md. Pitfalls to avoid: - Vague feedback (“be better at testing”). - Judgments about intent or character. - No follow-up or clear next step. ## 2) Resolving Interpersonal Conflict Framework: 1. Clarify the problem: Name the concrete disagreement (e.g., API shape, timeline, coding standard). 2. Assume positive intent; seek to understand: 1:1 conversations to gather goals/constraints. 3. Align on shared objective: Tie discussion to team OKRs, user impact, or SLAs. 4. Make it evidence-driven: Use data, experiments, design docs, ADRs. If needed, time-box a spike/POC. 5. Decide on a mechanism: Define decision owner (DRI) and criteria; if blocked, escalate thoughtfully with a concise brief. 6. Document and follow through: Record decision, rationale, and revisit date; verify outcome. Mini Example: - Conflict: Frontend wanted flexible, nested API; backend pushed for simpler, coarse endpoints for latency. - Approach: Facilitated a short design review; benchmarked both via a 2-day spike; data showed nested API added 18% latency at p95 on mobile. - Resolution: Chose coarse endpoint with a targeted expand parameter for needed fields; agreed to revisit after caching improvements. - Outcome: Latency improved, both sides’ core needs met, documented in ADR-127. Pitfalls: - Debating opinions without data. - No clear owner/decision rule. - Letting disagreements linger without closure. ## 3) When Success Metrics Are Missed Goal: Diagnose quickly, communicate clearly, and execute a focused recovery plan. A. Diagnose 1. Validate the metric: - Check definitions, logging, dashboards, and data freshness (e.g., is there pipeline lag?). - Confirm segments, filters, and time windows match the goal spec. 2. Quantify the gap and localize: - Break down by cohort, platform, region, funnel step; compare to baseline and control where possible. - Example: Target +10% activation; result +2%; Android +6%, iOS -1%; drop concentrated at Step 3 (permissions prompt). 3. Root cause analysis: - Review recent changes: releases, flags, dependencies, incidents. - Use 5 Whys and counterfactuals (what changed where the metric fell?). - Check leading indicators (latency, error rates, click-through) for early signals. B. Communicate with Stakeholders - Send a concise update: - What: Which metrics missed and by how much. - So what: User/business impact and risk. - Why (current best hypothesis): E.g., new permissions flow friction. - Now what: Immediate mitigations, owner-by-task, ETA, and monitoring plan. - Cadence: Set update frequency (e.g., daily until stabilized). - Keep it blameless, specific, and action-oriented. C. Course-Correct 1. Short-term mitigations: - Roll back risky changes or toggle flags. - Implement quick wins targeting the highest-impact bottleneck. 2. Focused experiments: - Form hypotheses, design A/Bs, define success and guardrails (e.g., “activation +5% without degrading p95 latency by >2%”). 3. Reprioritize and staff: - Allocate owners, adjust scope/timelines, involve cross-functional partners as needed. 4. Monitor and iterate: - Add real-time alerts and dashboards; validate uplift by segment. 5. Post-mortem (after stabilization): - Blameless write-up: root causes, what worked/failed, process improvements (e.g., pre-launch experiment, PRD metric validation, feature flags, canary rollouts). Mini Example: - Target: +10% new-user activation in Q3. - Result: +2% overall; analysis showed iOS Step 3 drop-off increased by 7% after adding a new permissions screen. - Actions: Rolled back the extra screen, shipped an in-context explainer variant via feature flag, and added pre-permission education. Activation rose to +8.5% within two weeks; maintained latency/error guardrails. - Follow-up: Instituted a pre-launch checklist for funnel steps and added a canary cohort for future permission changes. Common pitfalls: - Chasing anecdotes instead of segmenting the data. - Moving goalposts or redefining success midstream. - Overcorrecting without guardrails; skipping the post-mortem. # Putting It All Together in an Interview - Use STAR with measurable outcomes (numbers, timelines, error/latency/activation figures). - Show empathy and collaboration in feedback/conflict stories. - Demonstrate data-first thinking, clear stakeholder communication, and iterative execution for missed metrics. - Close the loop with learnings and durable process changes.