Discuss deadlines, feedback, and deep dives

These are behavioral prompts, so there is no single right answer—the interviewer is checking Amazon's Leadership Principles (Deliver Results, Earn Trust, Dive Deep, Ownership, Bias for Action) through real stories. Prepare one distinct, recent example per prompt. ## How to Answer - Use **STAR(L)**: Situation (context: team, system, scale, stakes), Task (your responsibility and success criteria), Action (3–5 specific steps, with trade-offs and reasoning), Result (measurable outcome), Learning (what you changed and applied later). - **Quantify** outcomes: latency (p95/p99), error/success rate, cost, on-call/paging load, customer impact, cycle time, revenue protected. - Say **"I"** for your contributions; clarify your unique decisions, code, and analysis instead of hiding behind "we." - **Show verification**: how you knew the fix or change actually worked (dashboards, tests, canary, A/B, customer metrics). - Keep each answer to ~60–120 seconds; trim setup, lead with the decisions and trade-offs. ## 1) Tight Deadline (sample answer) - **Situation:** Security flagged a critical zero-day in our auth library; we had 72 hours to patch three services with no downtime. - **Task:** Lead the patch, testing, and rollout across the services. - **Action:** Prioritized with MoSCoW (Must: upgrade library + regression tests + canary; Should: rollout automation; Won't-now: wrapper refactor). Timeboxed each phase, gated the rollout behind a feature flag with a 10% → 50% → 100% canary, kept changes minimal and reversible, and ran synthetic login tests in CI. Trade-off: deferred the wrapper refactor and doc polish to hit the SLA. - **Result:** Shipped in 36 hours, zero downtime, no auth errors, p99 unchanged, passed the security scan on the first pass. - **Learning:** Reversible, flag-gated changes plus an explicit cut-line let you move fast under pressure without risking the blast radius. ## 2) Missed Deadline (sample answer) - **Situation:** I committed to deliver an event consumer by Friday for a launch dependency. - **Task:** Integrate with an upstream event schema. - **Action:** On Wednesday the upstream schema changed and the pipeline broke. I immediately notified the PM and partner team with two options: ship partial read-only logging by Friday, or slip two business days and ship fully with dual-schema support. We agreed to slip with daily status updates. To mitigate, I delivered a stub logger so the partner could validate event volume, added consumer-driven contract tests, dual-version parsing, and a fallback toggle. - **Result:** Shipped Tuesday with backward compatibility, zero data loss, 100% green e2e; stakeholders stayed unblocked. The postmortem produced a schema-freeze checklist and CDC tests in CI. - **Learning:** Escalate early with concrete options, secure schema freezes for external dependencies, and buffer estimates for things you don't control. ## 3) Negative Feedback (sample answer) - **Situation:** In design reviews I was told I didn't present trade-offs clearly and came across as defensive in comments. - **Task:** Improve my design communication and collaboration. - **Action:** Adopted an ADR template (Problem, Options A/B/C with pros/cons, Decision, Risks, Rollback), summarized reviewer feedback in the doc and responded with evidence, scheduled short syncs for blocking items, and gave myself a 24-hour cool-off before replying to contentious threads. - **Result:** The next three designs were approved in a single review round; review cycle time fell ~30%; a peer survey noted clearer trade-off articulation. - **Follow-up / Learning:** I asked the same reviewers six weeks later to re-evaluate, and the ADR template became a team standard—closing the loop matters as much as the initial fix. ## 4) Beyond Requirements (sample answer) - **Situation:** The requirement was to build a new job-scheduler API endpoint with basic monitoring. - **Task:** Deliver the API and monitoring. - **Action:** Beyond scope, I added SLOs (99.9% of jobs starting within 2 minutes), exported Prometheus metrics with Grafana dashboards, wired an auto-rollback on elevated failure rate, and added a load test in CI plus a one-click rollback runbook. - **Result:** MTTR dropped from ~20 minutes to ~4 minutes, paging incidents fell 40% over two months, and the load test caught a memory leak before launch, avoiding an outage. - **Learning:** A modest amount of operational-excellence work at design time pays off repeatedly by cutting long-term toil and risk. ## 5) Dive Deep (sample answer) - **Situation:** Checkout p95 latency spiked from ~220 ms to ~900 ms after a release. - **Task:** Find the root cause and fix it without blocking orders. - **Action:** Listed hypotheses (N+1 queries, missing index, thread-pool saturation, GC pauses, third-party latency), then gathered data: before/after traces, the DB slow-query log, GC logs, thread dumps, and dependency health. The traces showed a new ORM call causing an N+1 (1 order → 17 item queries), confirmed by query count/time. Fixed it with a single JOIN plus a proper index, added a read-through cache, and wrote a regression test that asserts the query count. - **Result:** Verified via a 10% → 100% canary with stable dashboards; p95 returned to ~230 ms, error rate unchanged, no rollback. Added a tracing alert for query explosions to prevent recurrence. - **Learning:** Follow the data—traces → logs → profiling → targeted fix—and institutionalize a guard so the regression can't silently return. ## 6) Reverse Questions (ask the hiring manager) - **Expectations:** "In the first 90 days, what outcomes define success for this role, and how do you measure engineering impact—delivery, reliability, or customer metrics?" - **Team practices:** "What are the team's norms around code-review SLAs, testing, release cadence, and on-call, and how do you balance speed versus reliability (SLOs / error budgets)?" ## Pitfalls to Avoid - Vague outcomes—always quantify (time saved, error rate reduced, throughput improved). - Reusing the same story for multiple prompts; pick distinct examples that each highlight a different strength. - Blaming others—own mistakes and focus on root cause and prevention. - Forgetting the close: show how the fix or behavior change stuck (tests, alerts, check-ins, docs).

Rubric: the interviewer scores stories against Amazon's Leadership Principles using STAR(L). Strong answers are specific and recent, use "I" for the candidate's own decisions, quantify results, show explicit trade-offs and verification, and close the loop with a learning that was later applied. The reverse-questions prompt tests whether the candidate is evaluating the role and team thoughtfully.