Describe feedback, conflict, and missed metrics

# How to Answer Behavioral Questions Effectively - Use STAR or SBAR: - Situation/Background: Brief context (team, project, constraints). - Task: Your objective/role. - Action: Specific steps you took (focus on you, not “we”). - Result: Concrete outcomes (metrics, learning, behavior change). - Be specific, time-bounded, and measurable. Name the trade-offs and risks. - Show collaboration, ownership, and learning. Close the loop with follow‑ups you drove. --- ## 1) Giving Critical Feedback Approach framework (SBI + Ask + Align): - Situation & Behavior: "In last week's release review, you merged PRs without tests." - Impact: "This caused a 2-hour outage and delayed the hotfix." - Ask for perspective: "Can you share what happened from your side?" - Align on next steps: "Let's agree on pre-merge checks and a buddy review for the next 3 releases." Steps to execute well: 1) Prepare facts and artifacts: logs, PR links, failing tests, incident timeline. 2) Choose the right setting: private, timely, and with clear intent to help. 3) Be specific and non-judgmental; focus on behavior and impact, not personality. 4) Co-create a concrete plan with checkpoints. 5) Follow up and recognize improvement. Example (software-specific): - Situation: A teammate repeatedly bypassed CI because it was slow, causing flaky releases. - Task: As release owner, ensure reliability and improve process. - Action: Presented 3 instances with timestamps; used SBI; asked for constraints; learned CI queue times were 20–25 min at peak. Proposed: parallelize tests, introduce a 10-min smoke suite as required pre-merge, and add a branch protection rule. Agreed to buddy reviews for 2 sprints. - Result: Pre-merge smoke tests cut failures by 70% (from 10 to 3 per sprint). No outages for 6 weeks. The teammate adopted the checklist and later contributed to CI optimizations. What I’d improve: acknowledge their productivity pressure earlier and proactively prioritize CI speed before enforcing rules. Pitfalls: - Giving feedback in group settings; using labels (“careless”) vs. behaviors; no follow-up; unclear success criteria. --- ## 2) Handling Conflict with Peers or XFN Partners Approach framework (Interest-based problem solving): - Separate positions from interests: "Ship date" (position) vs. "Hit quarterly OKR and avoid regressions" (interests). - Align on shared goals: OKRs, success metrics, constraints. - Bring data: user impact, error rates, estimates, experiment results. - Co-generate options and trade-offs; agree on a decision rule (e.g., DRI, RACI). - Document the decision and pre-commit to re-evaluate based on signals. Example: Conflict on scope vs. reliability with PM - Situation: PM wanted to ship a social feature before a major event; I advocated for hardening due to rising crash rate on Android (0.8% → 1.6%). - Task: Balance user impact and reliability while meeting quarterly goals. - Action: 1) Aligned on goals: DAU +5%, crash rate <1%. 2) Showed cohort data: Android sessions down 3% week-over-week with top crash stack. 3) Proposed a plan: ship iOS (stable) as scheduled; for Android, cut two non-critical animations and fix top crash; run a 10% canary with guardrails (crash <1.2%, session length flat). 4) Agreed re-eval checkpoint after 48 hours. - Outcome: iOS launched on time; Android launched 5 days later with crash 0.9%. Overall DAU +4.2% in 2 weeks; no severity-1 incidents. Relationship improved because both sides felt heard. What I’d improve: preempt the conflict by adding a risk review 2 weeks earlier and maintaining a "must-fix" reliability dashboard. Tactics that help: - Use neutral language and curiosity (“Help me understand…”). Summarize the other side first. Offer multiple viable options with explicit trade-offs. Write a 1-pager so alignment persists after the meeting. Edge cases: - Power asymmetry (manager/stakeholder): ask for decision criteria; escalate with a facts-first memo if risk is unacceptable. Remote conflict: over-communicate in writing and confirm summaries. --- ## 3) When Success Metrics Are Missed: Diagnose, Realign, Course-Correct A practical playbook: 1) Verify measurement and setup - Is the metric defined consistently (numerator/denominator, window, timezone)? - Check data freshness, logging, and experiment assignment. Run an A/A test or sample-ratio check to catch randomization issues. 2) Quantify the gap - Baseline vs. actual: e.g., target +5% DAU; actual +1.2% (gap −3.8 pp). - Confidence: compute intervals or p-values; verify it’s not noise. 3) Localize the problem - Segment by platform, region, cohort, path. Funnel analysis: which step regressed? - Example: iOS +6%, Android −3%; drop isolated to low-end devices; funnel shows step “Open → Join session” fell from 72% to 63% on Android. 4) Generate hypotheses and map to levers - Performance regression? UX friction? Eligibility bug? Mis-targeting or cannibalization? - Prioritize by impact × confidence × effort. 5) Investigate quickly - Compare pre/post distributions and logs; check error rates, latency (e.g., P95 +200ms), feature flags, rollouts, and guardrails (crash rate, support tickets, churn). - Reproduce with test accounts and device farms. Look for confounders (seasonality, campaigns, concurrent launches). 6) Realign stakeholders - Write a concise brief: problem, evidence, hypotheses, options, risks, and recommendation. - Offer options with timelines: partial rollback, targeted fixes, ramp pause, or alternative experiments. - Confirm the decision owner and success criteria for the next checkpoint. 7) Course-correct and monitor - Implement the chosen fix (e.g., lazy-load assets on Android). Run a canary (10–20%) with clear stop conditions. Set alerts on primary and guardrail metrics. Hold daily standups until stabilized. 8) Learn and prevent recurrence - Postmortem with blameless root cause analysis (5 Whys, fishbone). Add pre-launch checklists, performance budgets, synthetic monitoring, and staged rollouts. Define leading indicators and adopt a ramp plan (1% → 10% → 50% → 100%). Mini numeric example: - Goal: +5% session starts. Observed: +1%. Segmentation shows Android −4%; P95 cold start +250ms after adding a heavy SDK. Fix: defer SDK initialization until after first render; canary shows Android +3.5% vs. control, guardrails stable. Full rollout yields overall +4.2%. Next time: enforce a 150ms performance budget in CI and require perf sign-off before feature freeze. Common pitfalls and guardrails: - Pitfalls: changing multiple variables at once, unclear ownership, ignoring guardrail metrics, over-indexing on average instead of segments. - Guardrails: run A/A or CUPED for variance reduction; monitor sample ratio mismatch; freeze other launches during diagnosis; document decisions and revisit on a set date. --- ## Putting It All Together in the Interview - Prepare 2–3 versatile stories you can tailor: one on reliability/process, one on product/metrics, one on collaboration/conflict. - Quantify outcomes (latency reduced by X ms, incidents down Y%, engagement up Z%). - Explicitly state what you’d do differently next time to show learning and growth.