Describe handling deadlines, conflicts, feedback, and ownership

# How to Approach These Prompts Use STAR (Situation, Task, Action, Result) plus Learning. Keep each answer to ~2 minutes, quantify impact, and emphasize ownership, bias for action, and ability to dive deep. When relevant, call out trade-offs, stakeholders, and risks. Helpful tools and concepts: - Prioritization: MoSCoW (Must, Should, Could, Won't), Impact vs. Effort, RICE. - Scope/risk: MVP definition, risk matrix (probability × impact), clear owners/due dates. - Debugging/deep dive: logs, metrics, tracing, profiling, query analysis, experiment/spike. - Alignment: ADRs (Architecture Decision Records), decision matrix, timeboxed experiments. - Communication: crisp updates, single source of truth doc, clear status and next steps. Guardrails: - Use non-confidential details; if you don’t recall exact numbers, give directional ranges and how you estimated. - Own mistakes; avoid blaming individuals. - Focus on what you did, not just what the team did. --- ## 1) Tight Deadline: Prioritization, Scope, Risk Template - Situation: Why the deadline was tight and the stakes. - Task: Your specific responsibility. - Action: Prioritization method, scope cuts, stakeholder negotiation, risk comms cadence. - Result: On-time delivery, quality metrics, follow-ups. - Learning: What you’d repeat/change. Sample answer - Situation: A critical bug caused checkout failures for ~8% of users two days before a major promo. - Task: Lead the fix and ship a patch within 24 hours. - Action: I triaged using MoSCoW, focusing on Must-fix paths and deferring non-critical UI polish. I proposed an MVP rollback plus a guarded fix behind a feature flag. I aligned with PM/Support in a 15-minute standup every 4 hours and kept a status doc updated. I flagged risks (possible regression in promo codes) and created a quick test plan plus canary deploy. - Result: Deployed in 20 hours, reduced failures from 8% to <0.5%, and avoided revenue loss. No new Sev-1s post-release. - Learning: Keep a pre-baked incident runbook and feature flags; small, reversible changes reduce risk. --- ## 2) Proactively Helping Others Template - Situation: Gap or pain point you observed. - Action: What you built/taught/standardized. - Impact: Time saved, quality improved, fewer escalations. - Learning: How you ensured adoption and sustainability. Sample answer - Situation: New engineers took ~3 days to set up the dev environment. - Action: I scripted environment setup (one command), wrote an onboarding guide, and ran a weekly Q&A. - Impact: Onboarding time dropped from ~3 days to ~1 day; 10+ engineers used it in the first quarter; fewer “it works on my machine” issues. - Learning: Pairing the guide with short videos and adding a feedback form increased adoption. --- ## 3) Deep Dive and Root Cause Analysis Template - Situation: Metric or behavior regressed. - Action: Hypotheses, data sources, tools (logs/metrics/traces/profilers), experiments/spikes. - Result: Root cause, fix, measurable improvement. - Learning: Prevention (tests, alerts, dashboards, guardrails). Sample answer - Situation: p99 latency regressed by ~35% after a feature release. - Action: I correlated release time with metrics, then used distributed tracing to pinpoint slow spans. CPU profiling showed heavy JSON serialization; DB logs showed an N+1 query triggered by a new flag. I tested batching queries locally and added a cache with a short TTL. - Result: Restored p99 to better than baseline (−42% vs. regression), reduced DB calls by 60%, added a canary + alert at p95 > threshold. - Learning: Add performance budgets in CI and a pre-merge load test for endpoints with new flags. --- ## 4) Conflict with a Colleague and Reaching Alignment Template - Situation: Disagreement topic and impact. - Action: Surface criteria, collect data, run a timeboxed spike, document trade-offs (ADR), decide. - Result: Aligned decision, rationale, and follow-through. - Learning: Process to prevent recurring debates. Sample answer - Situation: We disagreed on introducing a new message bus vs. extending the existing one. - Action: I proposed decision criteria (latency, ops overhead, cost, time-to-ship), ran a 2-day spike to measure throughput and failure modes, and documented results in an ADR. - Result: We chose to extend the existing bus with clear limits and a migration plan. We shipped 3 weeks sooner and met latency targets. - Learning: Criteria + spike + ADR defused opinions and created a repeatable pattern for future decisions. --- ## 5) Taking Work Outside Your Scope Template - Situation: Gap putting goals at risk. - Action: Why you volunteered, how you timeboxed, stakeholder expectations, updates. - Result: Unblocked path, measurable outcomes. - Learning: When to formalize ownership or hand back. Sample answer - Situation: On-call rotations were failing due to missing runbooks, causing longer incidents. - Action: I volunteered to create runbooks and basic automation, timeboxed to 10% capacity with my manager’s agreement, and shared weekly progress. - Result: Mean time to recovery improved from 45 to 18 minutes; on-call satisfaction increased in a post-rotation survey. - Learning: Formalize ownership after the pilot; we added runbook maintenance to the team’s quarterly goals. --- ## 6) Receiving Negative/Harsh Feedback Template - Situation: What was said and where. - Action: Seek specifics, own impact, create a change plan, ask for follow-up. - Result: Observable behavior change and outcomes. - Learning: What made the change stick. Sample answer - Situation: A senior engineer said my code reviews felt dismissive and blocked velocity. - Action: I asked for examples, realized my terse comments lacked context. I adopted a review template (what/why/suggested alternative), mixed praise with suggestions, and offered quick syncs for complex changes. - Result: Fewer back-and-forth cycles; PR median time to merge dropped from ~2.5 days to ~1.7 days; I was later asked to mentor on code review best practices. - Learning: Tone and clarity matter; a lightweight template avoids miscommunication. --- # Quick Checklist to Prepare Your Own Stories - Pick 1–2 strong stories that can flex across prompts (deadline + deep dive often combine well) and 2–3 additional targeted stories. - Quantify outcomes (performance %, error rate, time saved, revenue/risk avoided). - Name stakeholders and how you aligned with them. - Show trade-offs and what you explicitly de-scoped. - Close with learnings and durable artifacts (runbooks, alerts, ADRs, tests).