Amazon Behavioral Interview Questions: All 30 with STAR Answers (2026)

Situation: I was a product manager on a B2B SaaS platform. A mid-market client in the logistics sector flagged that our reporting dashboard was missing a shipment-delay breakdown they needed for their weekly board report. Technically, this was not a contracted deliverable, and the client’s contract renewal was four months away.

Task: I had to decide whether to treat this as a future roadmap item or act immediately, without a formal feature request ticket or budget approval.

Action: I partnered directly with our lead data engineer — outside our sprint cycle — to understand what data already existed in our warehouse. We built a custom export template using existing data within three days, and I personally walked the client through it on a 45-minute call. I also documented the use case and filed it as a roadmap proposal so future clients could benefit.

Result: The client used the report in their board meeting the following Monday and specifically mentioned it during their renewal negotiation two months later. They renewed at a 15% higher tier. The export template became a standard feature six months later, adopted by 40% of our enterprise clients.

Situation: Our engineering team had a hard deadline to migrate our platform off a legacy database before the vendor sunset the product. At the same time, our largest customer was mid-implementation on a feature that relied on the legacy schema and could not easily be paused.

Task: I needed to balance a non-negotiable technical migration with protecting a $2M ARR customer’s onboarding timeline.

Action: I mapped every customer touchpoint that depended on the legacy schema and identified a two-week window where the customer was in internal training and not actively building. I worked with engineering to sequence the migration so the customer-facing APIs migrated last. I also daily-briefed the customer’s technical lead throughout the window so there were no surprises.

Result: The migration completed four days before the vendor deadline and the customer onboarding experienced zero downtime. The customer went live on schedule and became a reference client used in three subsequent sales cycles.

Situation: My team was six weeks into building a new onboarding flow for our mobile app. We had designed it around three steps, each with a short animated walkthrough, which internal testing rated highly.

Task: Before full release, I ran an unmoderated usability study with eight real users from our target segment — first-generation smartphone adopters in smaller Canadian markets.

Action: The study revealed that two of the three animations confused users rather than helping them; they were skipping the steps entirely and trying to guess their way through the interface. I halted the release, shared the video recordings with the design team, and we reworked the flow to skip animation and use plain-language checklists instead. This required a two-week delay.

Result: Post-launch, our onboarding completion rate was 74%, up from 51% on the previous version, and the average time to first meaningful action dropped by 38%. The two-week delay was worth it and we used the usability framework for all subsequent feature releases.

Situation: A senior engineer on my team was delivering technically strong work but communicating in a way that consistently shut down discussion in design reviews — junior engineers had stopped contributing ideas in their sessions with them.

Task: I needed to address this without damaging a valued contributor or making them feel ambushed, while also protecting the team’s psychological safety.

Action: I observed two more design reviews to gather specific examples, not impressions. I then scheduled a dedicated 1:1 — separate from our usual meeting — and opened by naming what I valued about their technical leadership. I shared two specific incidents where I had seen junior team members disengage after their responses, described the business impact (fewer ideas, slower reviews), and asked for their perspective before offering any solution. They were genuinely surprised and asked for help.

Result: Over the next six weeks, I checked in with three junior engineers who had previously gone quiet. All three reported feeling more comfortable speaking up. The senior engineer later volunteered to run a team session on giving and receiving critique, which became a quarterly norm.

Situation: I had championed a vendor switch for our data pipeline tooling, projecting a 30% cost reduction. Three months after the switch, our infrastructure costs had actually increased by 12% because I had underestimated egress fees in the new setup.

Task: I needed to report this to the VP of Engineering and the broader infrastructure team, who had trusted my recommendation and committed budget based on it.

Action: I prepared a concise post-mortem before the all-hands. I did not minimise the gap or attribute it to factors outside my control. I presented the original analysis, the actual outcome, and the specific assumption that was wrong (I had used average egress figures rather than the peak-heavy pattern our workloads generated). I also presented three options for correcting course, with my recommended path.

Result: The VP approved the corrective path in the same meeting. Two engineers on the team later told me the transparency had increased their confidence in my judgement, not decreased it. I now require independent review of all cost projections before presenting them to leadership.

Situation: Our customer success team was fielding repeated complaints about incorrect billing statements, but the issue sat at the boundary between the billing engineering team and the finance operations team — neither owned it clearly. I was on the platform team, with no direct stake in billing.

Task: Customers were churning because of trust issues around invoices. After two escalations reached the CEO, I decided this was worth picking up even without being asked.

Action: I ran a two-day deep-dive: I pulled billing logs, interviewed three customer success reps, and traced the root cause to a rounding error introduced in a currency conversion update six months earlier. I filed a detailed bug report, proposed a fix with the billing team, and set up a bi-weekly sync between billing engineering and finance operations so future edge cases had an owner.

Result: The fix was deployed within two weeks. Billing-related support tickets dropped 67% over the following month. The billing–finance sync meeting still ran a year later and became the standard escalation path for payment issues.

Situation: My VP asked me to “do something about our data quality” with no further brief, no budget, and no dedicated engineering time. The ask came after a high-profile incident in which a quarterly business review contained a metric that contradicted our dashboard by 18%.

Task: I had to define the problem, propose a solution, secure resources, and deliver a measurable improvement — all without a formal project charter.

Action: I spent the first week auditing our five highest-priority dashboards and categorised data quality issues by root cause. I presented a one-page recommendation: focus on three tables that accounted for 80% of the discrepancies, build automated reconciliation checks, and assign a rotating “data owner” per table. I got two engineers allocated for six weeks by trading it against a lower-priority feature.

Result: By end of Q2, data discrepancies in the top dashboards dropped from 12 per month to 1. The data ownership model was adopted across all product lines and was cited in our next external audit as a governance best practice.

Situation: After joining a new team as tech lead, I introduced a requirement that all new code must have at least 80% unit test coverage before merge. The team had been operating without a coverage requirement, and three engineers pushed back, arguing it would slow delivery.

Task: I needed to raise the bar on quality without losing team trust or blowing our sprint velocity.

Action: Rather than mandate the change, I ran a data exercise with the team: I pulled our last 90 days of incident reports and showed that 71% of production bugs came from untested edge cases in our two most-changed modules. I then offered to pair-program the first two pull requests with each engineer to build the habit without burning extra time. I also adjusted our sprint capacity estimates to account for the new practice for the first two months.

Result: Within eight weeks, the team was hitting 85% coverage consistently and sprint velocity had returned to baseline. Production incidents in the affected modules dropped 60% in the following quarter. Two engineers later told me it was the single best change we had made as a team.

Situation: Our mobile app’s Day-7 retention rate was 22%, well below the 35% industry benchmark for our category. Churn was happening in the first three days, before users had experienced the app’s core value.

Task: I was tasked with improving Day-7 retention by 10 percentage points within one quarter, with no additional headcount.

Action: I ran a cohort analysis and found that users who completed one “saved item” action in the first 24 hours had 2.8x higher Day-7 retention. I redesigned the onboarding flow to surface the saved-item action within the first three screens, ran an A/B test (n=4,200), and killed two lower-performing variants after two weeks. I also set up a daily retention dashboard so the team could see the impact of each change in near real-time.

Result: Day-7 retention reached 34% within the quarter — a 12-point improvement — and held above 32% for the following two quarters without further intervention. I documented the methodology and it was used by two other product teams in the same org.

Situation: I had committed to delivering a new API integration by the end of Q3 for a partner who had planned their own launch around our timeline. Two weeks before the deadline, our underlying infrastructure team hit an unexpected capacity issue that blocked our work.

Task: I had to manage the expectation with the partner, find a path to partial delivery, and own the miss without deflecting to the infrastructure dependency.

Action: I called the partner’s technical lead within 24 hours of knowing we were at risk — before they chased me. I owned the miss clearly and did not lead with the infra dependency as an excuse. I then proposed a phased delivery: a read-only version of the API that would let them begin their QA process while we finished the write endpoints. I also escalated internally with a clear risk register so the infra fix was prioritised.

Result: The partner accepted the phased plan. The read-only API launched on the original date. Full API delivery was six days late — not three weeks, as it could have been. The partner’s launch was unaffected, and they expanded the integration scope the following quarter.

Situation: During a product launch, our analytics pipeline went down 48 hours before go-live. We had partial data for only 60% of our planned A/B test cells, making statistical significance impossible to confirm by launch time.

Task: I had to decide: delay the launch and wait for full data, or proceed on partial signal. Delay would cost us a major PR cycle and disappoint sales who had pre-briefed clients.

Action: I assessed what the 60% data actually showed. The directional signal was consistent across all available cells — no variant was underperforming. I identified the decision as reversible: if the variant showed harm post-launch, we could roll back in under two hours. I made the call to launch with the 60% signal, documented my reasoning and the rollback criteria, and set up manual monitoring for the first six hours post-launch.

Result: Launch went live on schedule. The variant performed as the partial data had indicated. Our analytics pipeline was fully restored 18 hours later and confirmed the decision. No rollback was needed. The PR cycle reached 3.4M impressions in the first week.

Situation: Our team was under pressure to respond to a competitor who had launched a feature we were planning. I pushed to ship a minimum version within one week without running our normal QA cycle — I had assessed the risk as low.

Task: My goal was to get to market within the same news cycle to blunt the competitor’s advantage.

Action: I cut four of our usual seven QA test cases, shipping what I judged to be a “good enough” verification. The feature launched on time but a regression in a related flow caused checkout errors for approximately 800 users over 90 minutes before we caught it.

Result: We rolled back within two hours and issued a customer apology email. No users were permanently impacted and we re-launched correctly three days later. I took this to the team as a lessons-learned: I had miscalibrated the “reversible decision” classification because checkout errors affect revenue immediately. I added a “payment-path” flag to our QA minimum checklist that can never be skipped. The flag has since prevented two similar scenarios.

Situation: We needed to run a competitive user research study against three rival products. The research budget had already been spent for the quarter, and the next study cycle was eight weeks out — too late for the roadmap decision we needed to make.

Task: I needed high-quality competitive insight within two weeks and effectively zero budget.

Action: I reached out to our customer success team and identified twelve power users who had previously used at least one of our three competitors. I ran 20-minute structured video interviews myself — evenings and one Saturday morning — using a standard usability protocol I adapted from published research. I synthesised findings in a shared doc and ran a 90-minute insight readout with the PM and design team.

Result: The readout directly influenced the roadmap decision: we de-prioritised one planned feature and fast-tracked another based on a gap all twelve participants named. Total cost: zero dollars and approximately 14 hours of my own time. The insights were rated as more actionable than our last commissioned study by the PM lead.

Situation: In Q4, two urgent requests landed simultaneously: a platform migration required by our biggest enterprise client for contract renewal, and a product-requested notification overhaul that sales had been promising prospects for six months. My team had capacity for one.

Task: I had to make the call and communicate it clearly to both internal stakeholders within 24 hours, since both teams were already planning resources against an expected “yes.”

Action: I built a simple decision matrix scoring each project on four factors: revenue at risk, client impact, reversibility, and strategic alignment. The migration scored higher on revenue risk (contract non-renewal > $400K ARR) and was a hard external deadline. I presented this to both stakeholders in the same meeting so neither heard a second-hand decision. I also proposed a scope reduction on the notification project so a partial version could launch in Q1 with reduced effort.

Result: The migration was delivered on time, the contract renewed, and the partial notification feature launched in early Q1 as promised. Both stakeholders cited the transparency of the decision process as a positive in their post-mortem feedback.

Situation: Our annual conference demo required a working version of a new AI-generated summary feature. Three days before the event, the summarisation model was producing occasional hallucinations in edge-case inputs that we hadn’t yet resolved.

Task: I had to decide whether to demo with the known flaw or pull the feature from the keynote, which would require last-minute deck changes and disappoint the CEO who had personally previewed it.

Action: I scoped the failure mode: hallucinations only occurred with inputs over 10,000 tokens. Conference demos would use sample inputs well under that threshold. I added a hard token limit to the demo environment as a safety rail, documented the known limitation in our internal issue tracker with an owner and due date, and briefed the presenter on what not to input live. I did not hide the limitation from my manager — I walked them through the guardrail and they approved the demo.

Result: The demo ran without incident. The hallucination edge case was resolved in the production release two weeks later. Three enterprise prospects who saw the demo requested follow-up calls, two of which converted within 90 days.

Situation: Our support team was spending 35% of their weekly hours manually classifying incoming tickets before routing them, using a keyword list that was two years out of date and required constant maintenance.

Task: I proposed building an auto-classification system as a 20%-time project, with no dedicated headcount or budget.

Action: I trained a fine-tuned text classifier on 12 months of historical tickets, using open-source tooling and our existing compute infrastructure. I built a confidence threshold: high-confidence classifications routed automatically; low-confidence ones were flagged for human review. I iterated with the support team through three feedback cycles to tune the threshold and categories. Total build time: six weeks evenings and weekends.

Result: The classifier handled 78% of tickets without human classification, with 94% accuracy. Manual classification time dropped by 29 hours per week across the team. The system saved approximately $40K in annual labour cost. It was later incorporated into the product as a paid add-on feature for enterprise clients.

Situation: Our team’s code review process required three approvals per PR, two rounds of static analysis, and a manual QA sign-off. Median PR merge time was 4.5 days, causing bottlenecks that slowed our sprint velocity and frustrated engineers.

Task: I volunteered to audit the process and propose changes without lowering our defect rate.

Action: I analysed six months of PR history and found that 88% of defects caught in review came from a specific set of 12 code patterns. I proposed: replace three-reviewer approval with two reviewers plus an automated linter rule set targeting the 12 patterns; remove the duplicate static analysis pass; and limit manual QA sign-off to PRs touching payment or auth code only. I presented the proposal with the defect-rate data and ran a four-week pilot on our lowest-risk service.

Result: Median PR merge time dropped from 4.5 days to 1.7 days. Defect rate in affected PRs was unchanged at 2.1%. The process was adopted across all three teams in the org within three months.

Situation: Our overall monthly active user (MAU) metric was growing at 8% month-over-month, and the team was preparing a positive QBR. I decided to break MAU down by cohort and feature usage before the review.

Task: I wanted to understand whether the growth was healthy across the user base or concentrated in a specific segment.

Action: I built a cohort-level MAU breakdown in our data warehouse and found that 100% of the growth was coming from a single new integration partner’s users who had activated in the last six weeks. Our organic MAU had actually declined 3% over the same period. I cross-referenced this with support ticket data and found that the integration partner’s users had a 90-day retention rate of 11% — far below our baseline of 44%.

Result: I presented this at the QBR in place of the positive headline. The team pivoted to focus on organic retention and diagnosed a broken activation flow for direct-signup users. Fixing that flow over the next six weeks returned organic MAU to positive growth. The partner cohort issue was escalated to the partnerships team for a co-designed onboarding programme.

Situation: Our entire growth strategy was built on the assumption that reducing sign-up friction would improve conversion. The team was planning a six-week sprint to remove three form fields from our onboarding flow.

Task: Before the sprint kicked off, I ran a quick analysis on our existing user quality data, specifically because something felt off about our churn numbers for users acquired through the already-simplified mobile flow.

Action: I found that users who completed the “longer” sign-up with all fields had 60% higher 30-day retention than users from the shorter mobile flow. The friction correlated with intent — users willing to spend 90 extra seconds were significantly more likely to become long-term customers. I presented this finding to the team with a recommendation to keep the fields for web and run a segmented A/B test on mobile only.

Result: The web version kept all fields. The mobile A/B test confirmed the retention pattern. We added a contextual progress indicator instead of removing fields, and conversion on mobile improved by 8% without sacrificing retention. The team adopted a “check retention, not just conversion” heuristic for all funnel experiments.

Situation: I was assigned to lead our GDPR compliance audit with a four-week deadline, despite having no formal privacy law background. Our legal team could advise but had no capacity to run the audit itself.

Task: I needed to become sufficiently expert to map our data flows, identify gaps, and produce an audit report that could withstand legal review — in four weeks.

Action: I spent the first three days reading the actual GDPR regulation text, two practitioner guides, and the ICO’s published enforcement cases from the previous year — not summaries. I then scheduled two-hour sessions with our legal advisor to validate my interpretation of the highest-risk areas. I built a data-flow inventory in a shared spreadsheet and completed gap analysis on 23 data processing activities. I flagged three significant gaps for legal review and proposed remediation plans for each.

Result: The audit report was completed in 19 days, five days ahead of schedule. Legal reviewed it and made only minor amendments. All three flagged gaps were remediated before the following quarter. I presented the methodology to our security team as a repeatable audit framework.

Situation: Our executive team decided to sunset a low-monetisation feature that 18% of our active users relied on daily. The decision was announced in a business review as final before engineering was consulted on the migration cost or user impact.

Task: I believed the decision was based on incomplete data — specifically, that the users relying on the feature had disproportionately high LTV and referral rates that weren’t captured in the monetisation metric being used.

Action: I requested a 30-minute review meeting with the CPO and presented a one-page analysis: the at-risk 18% had 2.4x the average LTV and generated 31% of our referral-sourced new users. I was not arguing to keep the feature forever — I proposed a 90-day migration path that included proactive outreach and an alternative workflow that met their core need. I was clear that I was raising a risk, not overruling a decision.

Result: The CPO delayed the sunset by two months to execute the migration plan I proposed. Churn from the affected segment was 6%, compared to an estimated 40% under the original abrupt shutdown. Two senior engineers later said the analysis changed how they thought about feature sunset decisions entirely.

Situation: My manager wanted to reduce our post-launch monitoring period from 72 hours to 24 hours, citing resource pressure. I believed 72 hours was the minimum needed to detect weekly-cycle patterns in our usage data.

Task: I had to decide whether to voice my disagreement formally or defer to their judgement as manager.

Action: I brought two historical incidents to our next 1:1: both had surfaced between hours 26 and 60 post-launch and had required rollbacks. I laid out my concern specifically: the reduction would eliminate our ability to catch issues that appeared only when Monday morning traffic hit the new code. I gave my manager the option to make the final call with that information. They decided to keep 72 hours for major releases and reduce to 24 for minor patches — a reasonable middle path I fully supported.

Result: The policy change was documented and I committed to it completely. At the next major launch, an issue appeared at hour 38 — within the window I had advocated for. We caught it before it impacted more than 0.3% of users. My manager acknowledged the data had been correct.

Situation: A junior data analyst on my team was technically strong but consistently under-communicated her findings, presenting raw tables in stakeholder meetings without narrative or recommendation. This was limiting her visibility and her impact.

Task: I wanted to help her grow without making her feel her current approach was inadequate — she was producing excellent analysis and I didn’t want to damage her confidence.

Action: I started inviting her to shadow two of my stakeholder presentations per month so she could observe how I framed data before the numbers appeared. After each session I gave her one specific observation. I then asked her to run the next data readout with me as the note-taker — removing the safety net gradually. I introduced her to the “so what, now what” framework for structuring insight slides and reviewed her drafts for three months.

Result: Within five months she was presenting independently to the VP level. She was nominated for a stretch assignment to join the annual strategy review team — a role historically held by senior analysts only — and accepted. At her annual review she cited the presentation coaching as the most impactful part of her year.

Situation: We were hiring a senior product manager and had two strong finalists: one with eight years of direct PM experience at a SaaS company, and one with five years of PM experience plus two years leading a customer success team in the same domain.

Task: The hiring panel was leaning strongly toward the first candidate based on title seniority. I had a different view and needed to articulate it clearly.

Action: I ran a structured debrief using our LP scoring rubric. The first candidate scored higher on Deliver Results and Invent and Simplify. The second candidate scored significantly higher on Customer Obsession — with the deepest domain knowledge of actual user problems I had seen in a PM panel in two years — and on Earn Trust, because of how they’d navigated cross-functional relationships in their CS role. Given our product’s customer-facing complexity, I argued those LPs mattered more at this stage. I presented the LP comparison side by side in the debrief.

Result: We hired the second candidate. Within eight months they had shipped two features specifically informed by their domain expertise that drove a 14% uplift in enterprise renewal rates. The first candidate would not have had that knowledge base.

Situation: I needed the infrastructure team to prioritise a database indexing fix that was causing slow query times for our product feature, but that team was owned by a VP three levels above mine and their sprint was already locked for the quarter.

Task: I had no authority to reprioritise their work, no budget to offer, and no escalation lever short of going to a VP — which I wanted to avoid if there was another path.

Action: I built a short impact analysis: the slow queries were adding an average of 2.1 seconds to our most-used API endpoint, which correlated with a 17% drop in feature engagement based on our latency–usage data. I framed this in the infrastructure team’s own language — they cared about P99 latency, not product engagement — and presented a single SQL index change that their team could merge in under 30 minutes. I asked for a 15-minute slot in their weekly planning to walk through it. I was not asking for a reprioritisation; I was asking them to evaluate whether one specific 30-minute task fit into their workflow.

Result: They merged the index in the following sprint. Endpoint latency dropped from 2.3 seconds to 0.4 seconds. Feature engagement recovered to baseline within two weeks. The infrastructure tech lead later brought me into their planning sessions when they were prioritising cross-product fixes.

Situation: Our company’s data infrastructure was a collection of siloed databases, one per product line, with no central data layer. Each team ran their own analytics independently, producing inconsistent metrics and duplicate reporting work. I proposed building a unified customer data platform that would serve all product lines and enable cross-product insights for the first time.

Task: The proposal required buy-in from four product VPs, a significant engineering investment, and a willingness to deprecate four existing reporting systems that each team had built themselves.

Action: I wrote a six-page PR/FAQ — Amazon-style — and circulated it for two weeks before any meeting, allowing stakeholders to annotate and raise questions asynchronously. I ran separate working sessions with each VP focused on the specific value to their team, not the shared value in aggregate. I proposed an eighteen-month roadmap with the first team going live in three months, so sceptics could evaluate before committing fully.

Result: All four VPs signed off. The first product line went live on the unified platform in three months as promised. Within a year, all four lines were on the platform and our first cross-product retention analysis identified a $1.2M upsell opportunity the siloed systems had been unable to surface.

Situation: While building our team’s incident response runbook, I realised that four other teams in the org were each building their own versions of the same document, duplicating effort and producing inconsistent standards.

Task: I saw an opportunity to build a shared incident framework that would benefit the entire engineering org, but I had no mandate to do this — it would have to be volunteer work on top of my team deliverables.

Action: I invited the team leads from all four groups to a working session and proposed a shared template format. I ran three 60-minute collaborative drafting sessions over three weeks and produced a master runbook framework with team-specific appendices. I presented it at the engineering all-hands and proposed an “incident response guild” for ongoing maintenance.

Result: All five teams adopted the framework. Mean time to resolution on P1 incidents across those teams improved by 34% in the following two quarters, measured against the baseline from the quarter before adoption. The guild became a standing forum of 12 engineers and was cited in our SOC 2 Type II audit as evidence of mature incident management practices.

Situation: We were planning to launch an algorithmic job-matching feature that would recommend open roles to passive candidates. Our initial model performed well on conversion but, during evaluation, I noticed that it was systematically underrepresenting candidates from certain postal codes — areas with higher proportions of recent immigrants and lower-income households.

Task: I raised this concern before the launch review, knowing it would delay our timeline by at least four weeks.

Action: I brought the bias analysis to the product review, presenting the postal code distribution gap alongside our conversion metrics. I recommended we engage our external fairness consultant, conduct an equity audit of the training data, and reweight the model before any user-facing deployment. I documented my concern formally in the launch checklist so it would require a sign-off to override.

Result: The fairness audit took three weeks. It identified two training data sources that introduced the bias. The corrected model showed a 19% improvement in underrepresented candidate matching with no reduction in conversion. We also updated our ML launch checklist to require equity audits for any recommendation system going forward. The revised process became our standard practice for all personalisation features.

Situation: After joining a new team, I noticed in our first three sprint retrospectives that the same five engineers (all senior, all male) dominated the discussion, and that contributions from newer and more junior members were rarely acknowledged or followed up on.

Task: I wanted to address the dynamic without calling it out in a way that created defensiveness or embarrassment.

Action: I proposed two low-overhead changes to our retrospective format: a silent brainstorm period at the start where everyone submitted ideas anonymously before verbal discussion began, and a structured “last word” rule where the facilitator asked if anyone not yet heard had something to add. I ran a working group of three people — including two of the quieter team members — to shape the format before proposing it to the full team.

Result: In the six retrospectives after the change, the number of contributors per session rose from an average of 4.8 to 8.3. Two ideas from junior engineers were prioritised and shipped in the following quarter. One of the previously quiet engineers later told me directly that the format change had made them want to stay on the team.

This question is hypothetical but should still be answered with STAR structure applied to your reasoning.

Situation: Based on my research into Amazon’s internal writing culture and what current Amazonians have described publicly, the six-page narrative process is widely valued but inconsistently implemented — some teams produce rigorous documents, others produce slide decks renamed as narratives.

Task: If I had six months and one change to make, I would focus on improving the quality and consistency of decision-making narratives across teams, not the format itself.

Action: I would propose a lightweight “narrative review” program — similar to Amazon’s Bar Raiser model but applied to written documents — where a rotating group of high-judgment Amazonians review a sample of team narratives each month and offer structured feedback. The goal is not compliance; it’s calibration. Teams that write better narratives make better decisions faster.

Result: The expected outcome: higher consistency in document quality, better institutional knowledge transfer, and faster onboarding for new hires who can read high-quality historical narratives to understand how decisions were made. The process cost is low; the compound benefit is significant.

Always end with what YOU personally did and learned — not what the team delivered. If your interviewer asks “what was your specific role in that?” mid-answer, it’s a signal you have been using “we” too much. Practise narrating your contribution in isolation before your loop.