Timeline: referral, then a recruiter call two weeks later that set up the phone screen for a week after that, then the onsite (four rounds) a week after that, and a rejection two days after the onsite.
Overall impression: the coding difficulty wasn't that high, basically all LeetCode Medium, and every round asked Leadership Principles (LP) questions. I think what got me in the end was System Design.
The recruiter call was mostly about introducing the role, confirming the timeline, asking whether I could relocate, and walking through the whole interview process. No technical content.
Phone Screen (45 min): one LeetCode problem, and the LP part was probably testing Ownership and Learn and Be Curious. There weren't any especially tricky follow-ups — they cared more about communication and explaining your thought process while you write code. For LP it was standard STAR, and they don't just listen to the story, they keep digging into the details. Overall it felt good, and I moved on to the onsite smoothly.
Onsite Round 1: another LeetCode problem, and they kept following up on time/space complexity and whether there was a better solution. I solved it slowly. There were two LP questions — one was another deep dive, and for one story they kept asking follow-ups for a few minutes straight.
Onsite Round 2: same format basically — a classic LC problem, vertical order traversal of a binary tree. I didn't get the indexing right at first, then got there off a hint. Two LP questions, Think Big and Earn Trust, and again they dug deep into people-related stuff.
Onsite Round 3 (I think this one was the Bar Raiser), System Design: design a Kindle reader. They wanted the API, the database schema, and the overall architecture, and then kept following up — what happens when the reader is offline, what if one account has multiple Kindle devices reading the same book at the same time, how do you sync reading progress, how do you keep different devices from overwriting each other's progress, how do you handle conflict resolution, how does the API stay idempotent, how do you guarantee data consistency. It was a lot — I spent a ton of time on the DB schema, API design, caching, the data sync flow, and consistency. Looking back now though, I think I answered way too much from the technical implementation side and didn't keep circling back to the customer experience and the high-level tradeoffs. I should have talked more about why I designed it that way and the tradeoffs between the different approaches.
Onsite Round 4: the LeetCode problem felt similar to one I'd seen before, solved it with DFS. LP was Dive Deep and Deliver Results, and the conversation leaned pretty technical plus scope and impact.
Summary:
- Coding: Amazon L5 actually has pretty high standards for coding.
- Leadership Principles: LP matters a lot more here than at most other companies. I'd recommend prepping at least 8-10 STAR stories, and ideally each one should cover multiple LPs, because interviewers keep digging into the details.
- System Design: my biggest mistake was spending the whole round talking about API, database, and implementation details. I should have proactively stated my assumptions, shown I understood the tradeoffs between different approaches, and kept framing the design around Customer Obsession.
Wishing everyone smooth interviews!
Discussion
Loading comments…