Here's what your interviewer would think: Strong Ownership signal — you showed genuine cross-boundary initiative with specific metrics, which is the most valued LP for SDEs. Customer Obsession came through naturally. Dive Deep was solid but your Earn Trust answer lacked the self-critical edge Amazon looks for. A Bar Raiser would likely rate this 'Inclined' — one stronger LP story pushes it to 'Strongly Inclined.'
156
WPM
Ideal range
3.4
Fillers/min
Good
60%
Talk Ratio
Aim: 50%
Competency Breakdown
Tap to see evidence
Ownership92
'Strongly Inclined' signal — you acted on behalf of the entire company, not just your team. The cross-repo PRs, measurable impact (14% → 1%), and organizational artifact (post-mortem template) are exactly what the Bar Raiser evaluates for this LP.
▼ See the moment
Customer Obsession86
Strong signal — you started with the customer and worked backwards. The automated migration tool (312/340 merchants, zero code changes) showed you rejected the easy path in favor of the right outcome. Quantification was excellent.
▼ See the moment
Earn Trust64
The feedback was acknowledged but the response lacked the vocal self-criticism that distinguishes 'Inclined' from 'Strongly Inclined' on this LP. Amazon wants to see you benchmark yourself — what specifically was wrong, measured with data, not just 'I was too harsh.'
▼ See the moment
Dive Deep80
Good technical depth with strong outcome metrics (2.3s → 180ms). Could have emphasized the moment where the data contradicted the accepted explanation more sharply — that's the core Dive Deep signal.
▼ See the moment
What You Did Well
Demonstrated textbook Ownership — took responsibility beyond your team's scope
Interviewer asked
Tell me about a time you saw a problem outside your area of responsibility and took ownership of fixing it.
You said
I noticed our deployment pipeline had a 14% failure rate that three other teams were working around by manually retrying deploys. Even though I owned the payments service, not CI/CD, I spent two weekends profiling the pipeline. I found a flaky integration test that passed locally but failed under load, and a race condition in the artifact cache. I submitted PRs to both repos, got the failure rate to under 1%, and documented the root cause in a post-mortem that became a template for the org. Three teams started deploying 2x more frequently after the fix.
Why this was effective
This is a 'Strongly Inclined' answer for Ownership — Amazon's most valued LP for SDEs. You identified a problem nobody asked you to fix, went deep technically (race condition, load-specific test failure), delivered measurable impact (14% → 1%, 2x deploy frequency), and created lasting organizational value (post-mortem template). The Bar Raiser would note: 'Acts on behalf of the entire company, not just their team.'
Ownership
Customer Obsession was embedded naturally — not forced
Interviewer asked
Describe a situation where you had to make a tradeoff between what was easy for your team and what was right for the customer.
You said
We had a payment processing change that would save our team 200 engineering hours per quarter by deprecating a legacy API. But 340 merchants still used it — mostly small businesses with limited dev resources. The easy path was a 90-day migration deadline with documentation. Instead, I built an automated migration tool that rewrote their API calls and ran it in a shadow mode for 2 weeks. 312 of 340 merchants migrated with zero code changes on their end. The remaining 28 needed 15-minute support calls. We hit our deprecation deadline and our merchant NPS actually went up.
Why this was effective
You started with the customer and worked backwards — which is literally the definition of Customer Obsession. The answer shows you understood the real cost (merchant disruption), rejected the easy path, and quantified everything. '312 of 340 with zero code changes' is the kind of specificity that makes a Bar Raiser write 'Strong Hire.'
Customer Obsession
Focus Areas
Your top improvements
high
Earn Trust answer was missing the 'vocally self-critical' signal Amazon values most
Interviewer asked
Tell me about a time you received critical feedback. How did you handle it?
You said
My manager told me my code reviews were too harsh and discouraging junior engineers. I started being more positive in my reviews and mentoring them one-on-one instead of just pointing out issues in PRs.
Why this hurts your score
This answer addresses the feedback, but it's missing the self-critical depth that Amazon's Earn Trust LP demands. 'I started being more positive' is surface-level. Amazon wants to hear you 'benchmark yourself against the best' and be 'vocally self-critical.' The answer doesn't show what specifically was harsh, what impact it had, or how you fundamentally changed your approach — not just your tone.
A stronger response
That feedback hit hard because I'd prided myself on technical standards. When I audited my last 20 code reviews, I realized 78% of my comments were 'wrong' statements and only 6% were questions. I was telling, not teaching. I rebuilt my review approach around three rules: (1) every criticism must include a specific 'here's why' explanation, (2) lead with a genuine strength in their code before any critique, and (3) for junior engineers, pair-review the first three PRs live instead of async. Over the next quarter, our team's PR cycle time dropped from 3.2 days to 1.4 days, and two junior engineers told me they started looking forward to my reviews instead of dreading them. The lesson wasn't 'be nicer' — it was that my communication style was actively slowing down the team I was trying to make better.
Your goal for next time
For Earn Trust, always include: what specifically you did wrong (with data), how you fundamentally changed (not just adjusted), and evidence that the change worked. Self-criticism should be precise, not vague.
medium
Dive Deep answer could have shown more skepticism when metrics and anecdotes disagree
Interviewer asked
Tell me about a time you had to go deep into the details to solve a problem.
You said
Our service was hitting p99 latency spikes every Tuesday at 3 PM. The on-call engineer said it was just a weekly batch job. I didn't accept that answer — I pulled CloudWatch metrics, correlated with deployment logs, and found that a Tuesday config push was triggering a cold-start cascade across 40% of our Lambda fleet. I implemented connection pooling and pre-warming, and p99 dropped from 2.3s to 180ms.
Why this hurts your score
Good technical depth and strong outcome metrics (2.3s → 180ms). The 'I didn't accept that answer' framing shows healthy skepticism. However, you could have emphasized the moment where metrics contradicted the anecdote more sharply — that's the core of Dive Deep: 'Leaders are skeptical when metrics and anecdotes disagree.'
A stronger response
Add the specific disconnect: 'The on-call engineer said it was a batch job, but when I checked, the batch job completed at 2:30 PM — 30 minutes before the latency spike started. That gap told me the batch job was correlated but not causal. I dug into what actually happened at 3 PM and found the config push schedule.'
Your goal for next time
For Dive Deep, always highlight the moment where you found the data disagreed with the accepted explanation — that's the LP's core signal.
Speech Analytics
Words Per Minute
156wpm
Ideal range (130–160 ideal)
Pace Variation
Moderate
Good variation keeps listeners engaged
Fastest moment
At 7:20 — "I started being more positive in my reviews"
Filler Words
3.4/min
Target: under 5/min
Here's exactly what you said:
“um”×4“like”×3“basically”×2“you know”×2
Worst cluster — 7:00-7:45
4 fillers in a 30-second window. Slow down and replace filler starters with a confident pause.
Hedging Phrases
1.5/min
Low hedging
Impact
Phrases like “I think maybe”, “sort of”, “kind of” weaken credibility. Replace with direct statements.
Vocal Confidence
74/100
Strong
HesitantModerateCommanding
Weak moment
At 7:15 — “I started being more positive in my reviews and mentoring them”
Strong moment
At 1:10 — “I noticed our deployment pipeline had a 14% failure rate”
How we measure this
Vocal confidence is scored from language patterns: direct statements score high (“I decided”, “We shipped”), deferential language scores low (“I would like to”, “Can you give me”).
Practice These Next
1.Tell me about a time you made a decision with incomplete data and it turned out to be wrong. What did you do? (Bias for Action + Earn Trust)
2.Describe a time you simplified a complex system or process. What was the tradeoff? (Invent and Simplify)
3.Tell me about a time you disagreed with your manager's technical decision. How did you handle it? (Have Backbone; Disagree and Commit)
How was your experience?
Rate the interview + report — your feedback shapes what we build next