Amazon Software Engineer Interview Experience — Five Onsite Rounds, LPs Woven Into Every One

Preparing for Amazon took me a good amount of time, and threads on this forum helped a ton, so I'm back to turn in my homework.

Before I get into it: the biggest difference between Amazon and other companies is that Leadership Principles aren't a separate round — they're baked into every single round. Across my five rounds, every one of them started with twenty to thirty minutes of LP questions before there was any time left to code. In a couple of rounds the LP conversation actually ran over, so I only got through a simplified version of the coding question. So if you put 80% of your prep into grinding LeetCode, you can very easily get tripped up here.

My prep approach was: break the last four years of my projects into twelve stories, write each one up as half a page using STAR, and tag each story with which LP(s) it demonstrates. Some stories cover three or four principles, some only cover one. That way, whatever principle I got asked about on the spot, I could immediately pull up the right story. I'd strongly recommend doing this — it's way more useful than memorizing questions.

Round 1

The LP questions were about Ownership and Dive Deep.

Specifically: tell me about a time you took ownership of something that wasn't technically your responsibility; and tell me about a time you dug into the details and found a problem nobody else had noticed.

He pushed really hard on the second question. I talked about debugging a production incident, and he kept going deeper — "how did you confirm it was this component," "which metrics did you look at," "why was your first hypothesis wrong." By the end we were basically doing a full technical post-mortem together. My takeaway here: for Dive Deep, the interviewer really will follow you all the way down, so your story needs real technical detail in it — you can't fake this one.

The coding question was the top k frequent elements problem. I first used a hash map to count frequencies, then walked through three ways to get the top k: full sort at O(n log n), a size-k heap at O(n log k), and bucket sort at O(n). The interviewer had me write the bucket sort version, since the frequency upper bound is n, so you can just allocate n+1 buckets directly.

Follow-up: what if this were a continuous data stream and you needed the current top k at any moment? I said you'd need to maintain a bidirectional structure mapping frequency to elements, similar to how an LFU cache works — a hash map plus a doubly linked list chaining together elements with the same frequency, so that when a frequency increments you can move the element in O(1).

Round 2

The LP questions were about Customer Obsession and Are Right, A Lot.

Questions: tell me about a time you scrapped an existing technical approach for the sake of user experience; and tell me about a time your judgment turned out to be wrong, and how you handled it.

I was pretty well prepared for the second one. I talked about a case where I stuck with an approach for two weeks and it eventually got disproven by the data, and I focused on three things: why I made that call in the first place, what signal made me realize I was wrong, and how long it took me to admit it and adjust. The interviewer was visibly taking notes when I got to the part about which day I started doubting myself.

My takeaway here: when you're talking about a mistake, don't rush to clean it up — clearly explaining "what I missed" is more convincing than emphasizing "but I fixed it quickly."

The coding question was the Asteroid Collision problem. Given an array where positive numbers mean moving right and negative numbers mean moving left, with absolute value as size, when two collide the smaller one explodes and equal-size ones both explode — find what's left at the end.

Classic stack application. I got a little tangled up on "when do you push vs. when do you keep popping," so I used a flag to track whether the current asteroid had already exploded. After I finished I ran through a few cases myself: [5,10,-5], [8,-8], [10,2,-5], [-2,-1,1,2] — that last one is the key case, since asteroids moving left at the very front will never collide with anything.

The interviewer gave positive feedback that I came up with that last case on my own. My advice: always find a few edge cases and test them yourself after you're done writing — Amazon cares a lot about this.

Round 3 — System Design

LP questions were Deliver Results and Bias for Action.

Questions: tell me about a project with a tight deadline that you still delivered; tell me about a time you made a decision with incomplete information.

The design question was to design a library management system — and specifically one that spans multiple library branches. It needs to support checking out, holding, and returning books, and the same physical book can't have overlapping borrow periods.

This one leaned more toward OOD and data modeling rather than pure distributed systems. The interviewer's focus areas were pretty concentrated:

Data model. I designed a few tables: Book (catalog-level info, keyed by ISBN), Copy (each individual physical book, tied to a branch, with a status), User, and Borrow Record. The key move here is separating "book" (the catalog entry) from "copy" (the physical item), since the same book can have multiple copies across different branches.

API design. I listed out searchBook, checkAvailability, reserve, borrow, and return. The interviewer focused a lot on how to design the search endpoint so it could both search by title and also tell you which branches currently have a given book available.

How to make lookups fast. I said index by ISBN, and build a composite index on the copy table by ISBN plus branch ID, so that "which branches have this book" is a single index lookup. Partition borrow history by user ID.

How to handle the return write path. This is where he got the most detailed. I said returning a book is a transaction: update the copy status to available, update the return timestamp on the borrow record, and if someone has a reservation on it, trigger a notification. He followed up with "what if the notification fails to send?" — I said notifications go through a message queue, the transaction only guarantees the first two steps, a failed notification can just be retried, and you shouldn't roll back the return because a notification failed.

How to guarantee no overlapping borrow periods. I said use optimistic locking or a state-machine constraint at the copy level — a given copy can only be borrowed while it's in the "available" state, and you use a conditional update to prevent two people from borrowing the same copy concurrently.

This round ran the full time on discussion, so there was no time left for a coding question.

Round 4 — Bar Raiser

The LP intensity clearly stepped up a notch in this round. Questions were on Have Backbone; Disagree and Commit, and Learn and Be Curious.

Questions: tell me about a time you disagreed with your manager and stuck to your own view; tell me about a time you ultimately disagreed but still committed; and what's something you've recently taught yourself, and why.

A lot of people flub the second question. The way I understand Disagree and Commit, the point isn't really the disagreeing part — it's whether, after the decision was made, you actually committed and gave it everything. In my example I specifically called out that "after the decision was made, I didn't relitigate it — instead I proactively went and shored up the exact risk I'd originally been worried about." The interviewer responded pretty positively to that.

The coding question was Course Schedule — determine whether you can finish all the courses.

Topological sort; I used the BFS approach with in-degree counting and a queue. After I finished, he asked two follow-ups: first, what if you need to return an actual valid course order; second, if a cycle is detected, can you print out all the courses that are part of the cycle? For the second one I said you'd use DFS with three-color marking — hitting a gray node means you've found a cycle, and you can trace back along the recursion stack to pull out the cycle. I didn't have time to actually write it, just talked through the approach.

Round 5 — Hiring Manager

LPs were Invent and Simplify and Hire and Develop the Best.

Questions: tell me about a time you simplified something complex; tell me about a time you helped someone else grow; and what do you think is the area you most need to improve in.

For that last question I talked about documentation and knowledge retention — I gave a concrete example of a time I didn't write a clear enough design doc, which caused problems for whoever picked up the project after me, and then talked about what I do differently now. My sense is that naming a real weakness plus a specific concrete fix lands much better than a fake answer like "I'm too much of a perfectionist."

The coding question was a simplified version of merge k sorted arrays: merge three sorted arrays into one sorted, deduplicated array.

Three pointers — each step take the smallest of the three current values, and skip it if it matches the last value you output. One thing to watch: once a pointer runs out, you need a sentinel value (like infinity) to keep it in the comparison, otherwise your branching logic gets messy. After I finished, I tested "three arrays with a lot of duplicates" and "one array is empty."

Follow-up: what if there are k arrays? Answer: use a min-heap holding the k current elements, giving O(N log k).

A few takeaways

1. LP is the main battlefield, not a side dish. Across my five rounds, total LP time exceeded total coding time. The twelve-stories-tagged-by-LP prep method is genuinely worth doing.

2. Dive Deep and Are Right, A Lot are the two hardest to bluff. The first requires real technical detail in your story; the second requires you to be able to calmly dissect your own bad judgment calls. You can't fake either of these.

3. The coding questions were medium-or-easier, but you're expected to test your own code with cases after you finish. I proactively constructed edge cases at the end of every single round, and multiple interviewers reacted positively to that.

4. Questions in the Bar Raiser round get sharper. Especially for disagree and commit — the emphasis needs to land on what you did after committing.

5. For the "what do you most need to improve" question, name a real weakness with a concrete improvement, not a canned non-answer.

Good luck to everyone.