Amazon Leadership Principles Behavioral Scenarios

# How to Use This Bank Twenty-four prompts, but you do not need twenty-four answers. A well-built bank of 10 to 12 stories covers all of them, because most prompts are the same story viewed through a different Leadership Principle. ## Amazon-specific mechanics that change how you answer - **Each interviewer is assigned specific Leadership Principles.** They are scoring evidence against those principles, not enjoying the anecdote. Give the evidence early. - **Say "I", not "we".** The most common rejection note on Amazon behavioral loops is that the candidate's own decisions were never visible. Name what you decided, what you wrote, who you convinced. - **Expect three to five follow-ups per story.** What data did you look at? What did you get wrong? What would you do differently? What did the people who disagreed with you say? Prepare the second and third layer, not just the headline. - **Two-way vs. one-way doors.** Amazon explicitly reasons about reversibility. Say which kind of door you were standing in; it is the fastest way to justify moving fast or moving slowly. - **Amazon runs on writing.** Working backwards from the customer, the PR/FAQ, the six-page narrative, and the weekly business review are the mechanisms a PM is expected to know. If your story involved a written artifact and a decision meeting, say so. - **Check the current Leadership Principle list on amazon.jobs before the loop.** Amazon has added principles over time, so do not rehearse a list from an old blog post. ## STAR, applied correctly - **Situation:** context and why it mattered, in two sentences. - **Task:** your responsibility and the success criteria you were held to. - **Action:** what *you* did, why, and the trade-offs you accepted. - **Result:** quantified impact, plus the durable change you left behind. Target about 90 seconds for the first pass, then go deeper when probed. Directional numbers are fine when exact ones are confidential; "roughly a third of tickets" beats no number at all. Useful impact math when you need to size a result: - Incremental revenue = traffic x conversion lift x average order value. - Incident reduction = (baseline incidents - post-change incidents) / baseline. **One correction to the way these prompts are usually packaged:** question 24 is not a STAR question. It is a hypothetical asking how you *would* triage. Answering it with a past-tense story is a common miss. Use the framework in section 7 instead. ## Build the bank: 10 to 12 stories, mapped | Story you prepare | Prompts it covers | | --- | --- | | Root cause of a production or metric failure | 1, 2, 3, 17 | | Scaling a manual or capped process | 4, 10, 21 | | Influence without authority on a roadmap | 5, 16 | | Conflict with peers that ended in a compromise | 6, 7 | | Conflict with your manager | 7, 8 | | Security or risk reduction in a legacy system | 9, 3 | | Cross-system integration launch | 10, 21 | | Acting alone during an incident | 2, 11 | | Customer discovery that changed the requirement | 12, 13, 14 | | Rescuing an angry, high-value customer | 15, 13 | | Mistake, missed commitment, and recovery | 19, 20, 18 | | Big bet under ambiguity | 22, 23 | For each story write down: a one-line summary, baseline and result metrics, your specific actions, the trade-off you accepted, the stakeholders you moved, the principles it evidences, and what you would do differently. That last field is asked more often than candidates expect. --- ## 1) Dive deep, troubleshooting, and complexity (prompts 1, 2, 3) **What they are testing:** Dive Deep, Ownership, Insist on the Highest Standards, and under time pressure, Bias for Action. Structure: symptom, segmentation, hypotheses ranked by fastest-to-inform, mitigation, durable fix, prevention. **Worked example (root cause, prompt 1):** - **S:** Checkout failures rose from 0.6% to 3% after a release, hitting revenue and customer trust. - **T:** Get the error rate back under 1% and stop it recurring. - **A:** Ran a war room; segmented errors by client, API, region, and payment method; used a layered five-whys. Three contributing causes: a partial schema rollout, a misconfigured feature flag, and traffic skew from one load balancer. Coordinated the rollback, disabled the flag, then added contract tests and canary alerts. - **R:** Error rate back to 0.5% in 45 minutes, and the class of incident stopped recurring after the new deploy checks. The hard part to narrate is the *multi-layer* bit: say explicitly that fixing the first cause did not fix the symptom, which is what forced the deeper pass. **Worked example (severe time pressure, prompt 2):** - **S:** Checkout conversion dropped 18% within 30 minutes of a release. - **T:** Restore conversion inside an hour while still learning the cause. - **A:** Segmented by device and region, which isolated it to mobile web; rolled the feature flag back to 5%; logs tied the 500s to a payment gateway timeout; failed over to the secondary gateway; opened an incident bridge with updates every 15 minutes. - **R:** Conversion recovered in 25 minutes, protecting roughly $420K/day of at-risk revenue. Added synthetic monitors and a 3-second timeout fallback. For prompt 3, lead with *what made it complex*: many owners, no single source of truth, irreversible data migration, regulatory constraint. Complexity is the answer, not the project. Pitfalls: reading code before isolating the affected segment, delaying communication, skipping the postmortem. --- ## 2) Scale, integration, and security (prompts 4, 9, 10) **Scaling (prompt 4).** Leadership Principles: Think Big, Invent and Simplify, Deliver Results. - **S:** Partner onboarding was manual and capped at 10 partners per week. - **T:** Raise capacity ahead of international expansion without adding headcount. - **A:** Mapped the manual workflow, found the repeated document checks, and shipped a self-serve portal with validation templates, a sandbox, and status tracking. Launched in one region first, fixed the defects it exposed, then rolled out globally. - **R:** Throughput went from 10 to 60 partners per week, cycle time from 10 days to 2, with a lower defect rate. **Security (prompt 9).** Leadership Principles: Ownership, Insist on the Highest Standards. - **S:** A legacy admin workflow had broad permissions and thin audit logging. - **T:** Cut risk without blocking operations. - **A:** Worked with security and engineering to classify permissions, introduce role-based access, require approval for sensitive actions, and improve audit logs. Phased the rollout so support was never blocked. - **R:** High-risk access dropped sharply, audit coverage rose, and no operational disruption. The trade-off to name out loud: a small amount of added friction on rare actions, accepted deliberately. **Integration (prompt 10).** Leadership Principles: Ownership, Deliver Results, Dive Deep. - **S:** A customer-facing workflow spanned billing, identity, notifications, and reporting. - **T:** Land a reliable launch across four dependencies you do not control. - **A:** Built an integration map, wrote interface contracts, defined end-to-end test cases, and ran a launch-readiness checklist. Assigned a single named owner to every cross-system failure mode. - **R:** Hit the target date with fewer post-launch defects, because each failure mode was exercised before rollout. --- ## 3) Influence, disagreement, and acting alone (prompts 5, 6, 7, 8, 11) **Terminology fix:** "Have Backbone; Disagree and Commit" is a *single* Leadership Principle with two halves, not two principles. It is often quoted as if disagreeing were the whole thing. The commit half is what interviewers actually probe: once the decision goes against you, did you execute it wholeheartedly, or did you relitigate it in Slack? Every backbone story needs an ending where you either changed the decision with evidence or committed to someone else's. **Convincing others (prompt 5).** Earn Trust, Are Right A Lot, Customer Obsession. - **S:** The team wanted a visual redesign; support and funnel data said the real pain was failed setup. - **T:** Change the roadmap with no authority over design or engineering. - **A:** Pulled support tickets, funnel drop-off, and customer quotes into a one-page decision brief comparing redesign against setup simplification. Asked each stakeholder to attack the assumptions, then folded their objections into a phased plan. - **R:** Setup work went first, activation improved, and the redesign shipped later against better evidence. **Compromise with peers (prompt 6).** - **S:** Engineering wanted to rebuild a service before launch; the business wanted the fastest possible release. - **T:** Find a path that managed technical risk and customer timing. - **A:** Asked engineering to write down the concrete failure modes, and the business to write down the minimum customer outcome. Landed on an MVP on the existing service with strict guardrails, plus a separate architecture milestone with a defined trigger. - **R:** Launched on time, avoided the highest-risk shortcuts, and the rebuild happened on schedule afterwards. **Backbone (prompt 7)** is the same shape with a harder ending: you escalated, you put the dissent in writing, and then either the data moved the decision or you committed publicly and delivered. **Disagreeing with your manager (prompt 8).** This is prompt 6 with a power dynamic, and interviewers ask it separately on purpose. Do not soften it into a peer story. - **S:** My manager favored feature A; the data suggested feature B had roughly 3x the revenue potential. - **T:** Get to the right roadmap call without turning it into a standoff. - **A:** Proposed a cheap test rather than an argument: an A/B on 10% of traffic, plus a shared ROI model, reviewed with design and engineering. Agreed up front what result would settle it. - **R:** B showed +6.2% conversion; we pivoted and delivered about $3.4M ARR over nine months. Had the test gone the other way I would have committed to A, and saying that is part of the answer. **Deciding without your manager (prompt 11).** Bias for Action, Ownership. - **S:** During an incident, a feature was causing customer-facing errors and my manager was unreachable. - **T:** Decide whether to disable it. - **A:** Assessed severity, reversibility, and customer impact. It was a two-way door, so I disabled the feature, notified stakeholders immediately, and wrote down the rationale. - **R:** Errors stopped, the feature returned after the fix, and my manager agreed because the reasoning and comms were already documented. The half of this answer that source write-ups usually omit: say which decisions you would *not* have made alone. One-way doors, anything with legal, security, financial, or PR exposure, still get escalated, and if nobody answers you escalate further rather than proceed. Showing that boundary is what separates Bias for Action from recklessness. --- ## 4) Customers (prompts 12, 13, 14, 15, 16) **Gathering requirements (prompt 12).** Answer all four sub-parts explicitly, because the interviewer is checking them off. - **Who you consulted:** customers, support, sales, solution architects, and the data itself, not just the loudest account. - **How you asked:** jobs-to-be-done style questions about the workflow and the workaround they built, not "would you use this feature". - **How you scaled it:** enterprise customers asked for custom reports; the underlying need was auditability, so we shipped configurable exports with standard fields instead of one-off dashboards. - **What you tracked:** adoption of the export, volume of custom requests (which fell), and support handle time. **Improving customer experience (prompt 13).** Lead with the baseline metric and the mechanism that keeps the improvement from decaying: instrumentation, a runbook, an alarm. **A customer with a unique background (prompt 14).** This one is about assuming less. Good material: accessibility needs, low-bandwidth or older devices, a non-English or right-to-left locale, a regulated industry, a first-time buyer with no domain vocabulary. The strong version shows you found the need through research or a support signal rather than an assumption, and that the fix generalized: accessibility and low-bandwidth work almost always improves the median customer too. **Demanding customer or critical complaint (prompt 15).** Clarify the real problem, size the business impact, ship a mitigation now, then a durable fix, then close the loop. - **S:** An enterprise client's export failures were blocking their quarterly close. - **T:** Restore exports within 24 hours and prevent recurrence. - **A:** Set up executive-level comms, provided an SFTP fallback the same day, pulled the bugfix into the sprint, published an RCA, and added export retries with backoff. - **R:** Unblocked in 6 hours, retained about $1.8M ARR, and their NPS moved from 4 to 9 after follow-up. If the request genuinely does not fit the roadmap, say so plainly and offer the workaround. Interviewers reward the honest no more than the vague yes. **Customer-obsessed decision against another stakeholder (prompt 16).** - **S:** Sales pushed a bespoke feature that would have delayed an accessibility fix affecting a large share of users. - **T:** Maximize long-term customer value without torching the relationship. - **A:** Quantified both sides (accessibility affected roughly 18% of users; the deal was about $400K ARR), then proposed a modular path: accessibility first over two weeks, then a configurable version that would serve future deals rather than one account. - **R:** Accessibility shipped, MAU rose about 6 points, and the deal closed a quarter later with little custom work. Share the scorecard, not just the verdict. Reach, impact, confidence, effort, written down, is what makes this Customer Obsession rather than preference. --- ## 5) Obstacles, course corrections, mistakes, missed commitments, ownership (prompts 17, 18, 19, 20, 21) **Obstacle (prompt 17).** Name the obstacle precisely: a dependency that slipped, a person who would not move, a constraint you discovered late. Generic "it was hard" answers score nothing. **Course correction (prompt 18).** Ownership, Learn and Be Curious, Deliver Results. - **S:** Halfway through a project, user testing showed the flow solved the wrong problem. - **T:** Reset direction without losing the launch window. - **A:** Shared the evidence within a day, paused the low-confidence work, and rescoped the MVP around the top user pain. Communicated what changed, what stayed, and why, so nobody heard it secondhand. - **R:** Shipped a smaller and more effective release, and avoided another month spent on the wrong solution. **Significant mistake (prompt 19).** Own it, state the customer impact, then mitigation, then the systemic fix, then what you do differently now. - **S:** Launched a pricing change without updating pro-rated refunds. - **T:** Fix the billing discrepancies and rebuild trust. - **A:** Paused the rollout, issued credits proactively rather than waiting for complaints, added billing test cases, and put a go/no-go checklist in place with legal and support. - **R:** 96% of affected users credited within 48 hours, CSAT back from 3.1 to 4.6 in two weeks, no repeat. Pick a mistake with real stakes. "I was too detail-oriented" reads as an evasion and usually costs more than the mistake would have. **Missed commitment (prompt 20).** - **S:** API v2 slipped three weeks because the auth integration was under-scoped. - **T:** Replan to minimize business impact. - **A:** Communicated the slip the day it was knowable, not at the deadline; offered options across scope, resources, and schedule; negotiated a phased launch with read-only first; added API mocks and contract tests so the estimate would hold. - **R:** Shipped the phased release on the revised date, migrated 78% of traffic within two weeks, support tickets down about 45% versus v1. **End-to-end ownership (prompt 21).** Show the whole arc, not a handoff. - **S:** A new onboarding flow had low adoption. - **T:** Improve activation and retention. - **A:** Defined the north-star metric (day-7 activation), ran jobs-to-be-done interviews, led the redesign, instrumented the funnel and the lifecycle emails, trained support, and owned the QA checklist. - **R:** Activation up 14 points, 90-day retention up 7, onboarding tickets down about 32%. --- ## 6) Ambiguity and Think Big (prompts 22, 23) **Limited data or unfamiliar domain (prompt 22).** Give the framework, then the story. - Classify the decision as reversible or irreversible, and spend analysis budget accordingly. - Name the two or three uncertainties that actually move the outcome, and design the cheapest experiment for each. - Use analogs and priors where you have no data, and state your confidence honestly. - Set stop/go criteria and a rollback trigger *before* you start. - **S:** Entering a new vertical with an AI feature and almost no labeled data. - **T:** Decide the MVP scope. - **A:** Interviewed 12 target customers, ran a concierge test with 50 users doing the task manually behind the scenes, and pre-committed to a bar of at least 15% task-time reduction. Instrumented error types so failures were diagnosable. - **R:** Hit 19%, greenlit the MVP, and later saw about 11% upsell. Guardrails worth saying aloud: timebox the analysis, do not overfit to three loud interviews, and define what would make you kill it. **Think Big (prompt 23).** Vision, the customer insight underneath it, the strategy, the incremental bets, the impact. - **S:** Onboarding took 12 manual steps and SMB customers churned before reaching value. - **T:** Reimagine it as near zero-touch. - **A:** Wrote a PR/FAQ for the end state, proposed data ingestion via OAuth plus smart defaults, and sequenced it in three phases (import, guided config, auto-detection) with a partner SDK. - **R:** Time-to-value from 2 days to 30 minutes, activation up 22 points, churn down 4 points, and a partner ecosystem worth roughly $5M in first-year pipeline. Pair the 10x vision with a 10% first increment. Vision with no shipping increment reads as a daydream; increments with no vision read as a backlog. --- ## 7) The one hypothetical: triaging a customer's cloud-connectivity issue (prompt 24) Do not tell a story here. Show a triage structure, and note that as the PM your job is scoping, prioritization, communication, and the durable fix, while engineering and SRE own the packet-level work. 1. **Clarify and scope.** Who is affected: one tenant or many? Which regions, ISPs, client versions? When did it start? What exact error codes? What is the SLA and revenue exposure? Set severity: production outage, data loss, or broad revenue impact is a Sev-1. 2. **Stabilize before you diagnose.** Offer a workaround, an alternate region or endpoint, cached or offline mode, retries, a manual export. Throttle or feature-flag to shed load if the system is degrading. 3. **Isolate the layer, cheapest-to-inform first.** - Client: version, TLS and certificate state, recent config changes. - Network: DNS resolution, latency, packet loss, firewall, security group and ACL rules, NAT, proxy. - Identity: expired tokens, clock skew, OAuth scopes. - Service: health dashboards, 4xx versus 5xx split, dependency status, rate limits. - Cloud infrastructure: region or zone event, peering, gateway, CDN or WAF, TLS handshake failures. 4. **Collect evidence that supports a cohort analysis.** Timestamps, request and trace IDs, error codes, affected endpoints, sample logs. Correlate by region, ISP, and client version; the cohort that is *not* affected usually names the cause. 5. **Coordinate.** Open an incident channel with clear roles (incident commander, comms, resolver, scribe). Update every 15 to 30 minutes. Post to the status page once more than one customer is affected. 6. **Remediate and validate.** Roll back the recent change, fail over, raise timeouts, purge bad DNS or cache, rotate certificates. Confirm recovery with synthetic checks *and* with the customer before declaring it closed. 7. **Aftercare.** RCA within 48 to 72 hours with root cause, contributing factors, actions, owners, and dates. Then the preventive work: runbooks, monitors, canaries, circuit breakers, rate-limit policy. Small worked case: 502s spike for EU customers only, right after a deploy. The regional cohort points at the EU CDN configuration; rollback plus a cache purge restores service in about 20 minutes; the durable fix is a canary and regional smoke tests so the next bad config never reaches all of EU. --- ## Common failure modes across the whole bank - Telling a team story with no visible personal decision. - No numbers at all, or numbers with no baseline. - Blaming another team, a vendor, or a previous manager. - Answering the hypothetical with a story, or the story prompt with a framework. - Backbone stories that never reach the commit half. - A "mistake" that is secretly a humblebrag. - Running 5 minutes deep on the first pass, leaving no room for the follow-ups that actually score.

Rubric: the interviewer is scoring evidence for assigned Leadership Principles, not story quality. A strong answer makes the candidate's own decision visible ("I decided", not "we decided"), states the baseline and the quantified result, names the trade-off that was accepted, and survives three to five follow-ups on data, dissent, and what they would do differently. Conflict prompts must reach the commit half of Have Backbone; Disagree and Commit. Bias for Action prompts must show the reversibility test (two-way door acted on, one-way door escalated). The cloud-connectivity prompt is a hypothetical and is graded on triage structure, severity scoping, customer communication and aftercare, not on a past story. Weak answers are team-shaped with no personal decision, unquantified, blame-shifting, or run so long on the first pass that the follow-ups never happen.