Amazon Leadership Principles — Behavioral Stories (STAR)

Improving my code-review process after critical feedback

• Amazon LPs — Learn and Be Curious · Earn Trust · Insist on the Highest Standards · Hire and Develop the Best
• Situation — As I grew on the team, I started reviewing pull requests from junior engineers. In a 1:1, my manager gave constructive feedback: my reviews were technically correct, but I often reviewed PRs between meetings, dev work, and Slack messages — so some edge cases slipped through and were caught later in QA.
• Situation — Reflecting, I agreed. I wasn't treating reviews as focused engineering work — they'd become something I squeezed in between tasks.
• Task — I wanted to improve the quality and consistency of my reviews to give better guidance and catch issues earlier in the cycle.
• Action — Instead of just trying to 'be more careful,' I changed my process: I blocked a dedicated 90-minute focus window for PR reviews — notifications off, no meetings, no switching back to my own code.
• Action — I reviewed more systematically: beyond 'does it work,' I focused on edge cases, readability, maintainability, performance implications, and coding standards. Teammates learned my review window and planned submissions around it, making the process predictable.
• Result — I became more confident in review quality, fewer issues escaped to QA, and junior engineers got detailed, actionable feedback instead of quick approvals.
• What I Learned — Receiving critical feedback isn't about defending your current process — it's a chance to improve how you work. That mindset stuck, and I keep looking for ways to refine my engineering practices.