Background
This candidate was a mid-level software engineer with a background in cloud infrastructure and infrastructure as code. They were preparing for an Amazon SDE II loop.
They had already scheduled the interview, and they practiced over about a day.
With that little time, rebuilding every story from scratch wasn't an option. The useful question was narrower: which habits in their current answers would cost them points, and could they fix those before the loop?
The challenge
The first two sessions scored low, and the coach's feedback clustered around one theme. The candidate kept undercutting their own judgment.
They used phrases that played down their experience before they had described it. They said "we" for decisions they had made themselves. And the scaling numbers they said out loud didn't match the ones on their resume. An interviewer with the resume in front of them would notice. The coach told them to reconcile the two.
Their stories had the same pattern. In a conflict story, they described working around a disagreement with a vendor instead of pushing back on the architectural trade-off. They described checking changes by hand in the console, when someone with an infrastructure-as-code background is expected to talk about automated validation. When follow-up questions pressed on workload trade-offs, they contradicted themselves.
What they did
The turning point was switching from full mock interviews to short question sets aimed at specific weak answers. Instead of running the whole loop again, they reworked one answer at a time.
The coach's fixes were concrete:
- say what you have done and how deeply, without the disclaimer
- say "I" for the decisions you made
- use one set of numbers, and make it match the resume
Their second short set scored 4.4. Late coaching added two more asks. Spend the first 30 seconds on context: the system, the scale, the stakes. And include long-term business metrics after deployment, not just the launch.
The results
The fixes didn't all carry over at once. When they went back to full mock interviews, the scores dropped again. Fixing one answer in isolation is easier than holding every fix across a full interview. They ran one last short set before the loop, and it matched their best at 4.4.
Across the day, their average coach score went from 2.95 in their first two sessions to 3.85 in their last two. The coach's rating of how confident they sounded rose from 3.0 to 3.6.
They didn't tell us how the real loop went, so we won't guess.
What other software engineers can take from this
Check your numbers against your resume. If you say one latency or cost figure and your resume says another, that is the detail the interviewer will remember. Reconcile them before the loop.
Drop the disclaimer. A phrase that plays down your experience gives the interviewer a reason to lower your score. Say what you have done and how deeply. The software engineer interview guide covers how to frame depth honestly.
Show the disagreement, not just the workaround. For conflict questions, describe the trade-off you argued for and how it was resolved. The Amazon software engineer interview guide maps these questions to the Leadership Principles.
Test the fix in a full mock. Short sets are the fastest way to repair an answer. A full mock tells you whether the repair holds. The Amazon interview guide covers what the rest of the loop looks like.
If your Amazon loop is already on the calendar, you can run a few mock rounds on Revarta and find the answers most likely to cost you points.
