Hey everyone,
I recently went through the interview process for an SDE II role at Amazon, and wanted to share my experience.
The process consisted of a phone screen followed by a full interview loop covering LLD, DSA, HLD, and Leadership Principles.
The Beginning
I was contacted by an Amazon recruiter for an SDE II opportunity.
The initial phone screen was scheduled for 2nd July 2026.
I had been preparing primarily around DSA, but I knew the full loop would require much more than that — especially LLD, HLD, and Leadership Principles.
2nd July 2026 — Phone Screen
The phone screen was a DSA round.
The question was:
Count the number of subarrays whose sum is K.
There were around 2–3 follow-ups.
I was able to solve the problem and handle all the follow-ups very smoothly.
Overall, I felt the round went really well.
Preparation
The full loop was going to cover:
- LLD
- DSA
- HLD
- Leadership Principles
I spent a lot of time preparing for LLD and system design, since those were areas I wasn't as comfortable with initially.
I went through a lot of interview experiences and articles on LeetCode. I tried to go through as many 2026 Amazon interview experiences as I could find and made notes of the DSA and design questions that had been asked.
This helped me get a better idea of what kind of problems I could expect and prepare around the patterns rather than just randomly solving questions.
Full Loop
I specifically wanted all my interviews to be on different days so that I could get a fresh start for every round.
The original schedule was:
- 27th July — Bar Raiser + LLD
- 28th July — DSA
- 29th July — DSA
- 31st July — Hiring Manager + HLD
The 28th July DSA round was later rescheduled to 4th August.
So the actual sequence ended up being:
- 27th July — Bar Raiser + LLD
- 29th July — DSA
- 31st July — Hiring Manager + HLD
- 4th August — DSA
One thing that was slightly unexpected for me was having the Bar Raiser as the very first round, and having it be an LLD interview.
From the interview experiences I had read, I had seen many candidates have the Bar Raiser towards the end, often as a problem-solving round.
LLD was also not the area I was most confident in, so starting the loop with that was definitely not ideal from my perspective.
27th July — Bar Raiser | LLD + Leadership Principles
This was probably the round I was most nervous about.
The interview was around 60 minutes.
We spent the first 25–30 minutes discussing my resume and past experience. The interviewer cross-questioned me quite a bit, but I was able to answer the questions properly and felt that this part went reasonably well.
Then we moved to the LLD question.
The problem was around designing a system that handles audio buffers across different stages at X frames per second.
Initially, I honestly did not understand the problem very well. I asked for some time to understand exactly what was expected, and the interviewer mentioned that this was a genuine engineering problem their team was working on.
I got stuck pretty early on trying to figure out what the actual design flow should look like.
After a few hints, I started breaking the problem down into entities and worked towards a normal flow.
The interesting part was that I got quite engaged in the discussion with the interviewer. We kept going deeper into the system design and, before we realized it, we had spent most of the available time discussing the HLD aspects of the problem rather than the LLD implementation.
With only around 5–10 minutes left, the interviewer asked me to code whatever I felt was ideal for the design.
I quickly wrote a few classes and functions, but we ran out of time.
I wasn't particularly happy with my performance in this round. It wasn't a great way to start the loop, especially because LLD was already an area I wasn't very confident in.
The LP discussion was also part of the round and went reasonably well.
29th July — DSA + Leadership Principles
The interviewer was quite chill. He joined around 5 minutes late, so we quickly went through introductions.
We then spent around 15–20 minutes on Leadership Principle questions.
There were also some network issues that took another few minutes.
Then we moved to the DSA problem.
The question was around designing a file-system storage cache.
The interviewer first asked me for my approach.
The first thing that came to my mind was that storage itself wasn't really the core of the problem — the important part was the eviction policy.
I proposed using LRU as the eviction policy, with a doubly linked list + unordered map to achieve O(1) average-time operations.
The interviewer agreed with the approach and asked me to start coding.
While coding, he asked whether, when moving a node in the linked list, we need to delete the existing node and create a new one at the head, or whether we can simply reposition the existing node.
I got confused for a while and initially thought we should delete and recreate the node because of concerns around dangling pointers.
After thinking about it, I realized that wasn't necessary, and we spent a few minutes discussing that.
Later, he clarified another aspect of the problem.
He asked whether the cache was supposed to store just the file path and file name, with the actual file content being fetched from disk when required.
I thought that would be a reasonable design from a storage perspective. If we stored the complete file content and one file happened to be very large, it could consume a significant portion of the cache capacity.
I explained that the decision should ultimately depend on the requirements, and he agreed.
He then asked me to modify the solution so that the cache stored the file content itself.
I made the required changes and continued coding, but we eventually ran out of time before I could complete all the functions.
A fair amount of time had gone into the discussion around the linked-list implementation and the cache requirements, along with the earlier network issues.
Overall, the interviewer seemed satisfied with my reasoning.
I felt that with slightly better time management, I could have completed the entire implementation.
31st July — Hiring Manager | HLD + Leadership Principles
The Hiring Manager round was focused on HLD + Leadership Principles.
One thing I had consciously decided during preparation was to first build the happy path and get the basic architecture working before going deep into edge cases and scalability.
The question was roughly based on a scenario where a third-party service, such as Spotify, wanted to use Amazon Alexa to broadcast or notify users about a newly launched feature.
I initially started with entity models and some lower-level details, but the interviewer clarified that he was primarily interested in the HLD flow rather than those details.
So I shifted gears and started with the happy path.
I designed the initial flow using the relevant services, and the interviewer agreed with the direction.
He then started pushing deeper into failure scenarios.
One of the major discussions was around what happens when the device is offline, which led us into a deeper discussion around fallbacks and fault tolerance.
There were a couple of moments where the way the question was framed confused me for a few minutes, but once I understood what he was looking for, I was able to reason through the scenarios and answer them.
The interviewer also asked several product-decision-related questions.
I tried to answer these from both a technical and product perspective, rather than simply choosing the technically easiest solution.
He appreciated the product thinking and seemed satisfied with the discussion.
Towards the end, we also had a short discussion about the team and some of the engineering problems they were working on.
We also discussed GenAI and how I use it in my day-to-day development workflow.
Overall, I felt this round went well.
4th August — DSA + Leadership Principles
This round was originally scheduled for 28th July, but was later rescheduled to 4th August.
The interviewer started with some questions around my resume and seemed quite impressed with my past work experience.
After around 15–20 minutes, we moved to the DSA problem.
The problem was around course dependencies.
Imagine a college where some courses have prerequisites — for example, course A needs to be completed before course B. A student can take at most K courses in each semester.
If more than K courses are available in a semester, the priority for choosing courses depends on the maximum downstream depth of a course.
The goal was to determine the minimum number of semesters required to complete all the courses optimally.
The initial part was fairly straightforward — use topological sorting to handle the dependencies.
The more interesting part was deciding which course to pick when more than K courses were available.
The approach that came to my mind was a greedy strategy:
- Calculate the downstream depth of every course using DFS.
- Use a max heap to prioritize courses with the maximum downstream depth.
- Process the courses using topological sorting while selecting the highest-priority available courses.
I asked the interviewer multiple times whether we were on the same page with the approach, and she confirmed that we were. She didn't correct the approach at any point.
I coded the entire solution, explained the time and space complexity, and she seemed fully satisfied with the answer.
At the end, she also appreciated my thought process before we wrapped up.
After the interview, however, I thought about the problem more deeply and realized there could be an issue with the greedy strategy.
The relationship between a course and all of its descendants can affect which course should be prioritized, rather than just its maximum depth.
This made me wonder whether the actual optimization problem might be significantly harder, potentially even NP-hard depending on the exact formulation.
So I was left wondering how the interviewer evaluated my solution. From the interviewer's reactions, though, the approach seemed to be accepted and the discussion went well.
The Coincidence
There is one slightly personal part of this experience that I wanted to include.
Getting into a FAANG company has been a personal goal of mine for a long time.
Before starting this Amazon loop, I consciously tried not to compare the dates and timings with my Google interview last year.
But somehow, the coincidence was almost impossible to ignore.
My final Google round was on the 4th.
My final Amazon DSA round also ended up being on the 4th.
The Google round had been rescheduled.
The Amazon DSA round was also rescheduled.
The Google round was a DSA round from 1–2 PM.
The Amazon round was also a DSA round from 1–2 PM.
And the biggest difference:
In that Google interview, I wasn't able to solve the question.
This time, I was able to solve the problem.
So coming out of the Amazon loop, I genuinely felt that my overall interview packet was slightly better than what I had managed to put together for Google.
For a moment, I thought maybe this was finally it.
The Result
After the interviews, I didn't hear back for around 3–4 days.
I started feeling that something might not have gone my way.
You hear so many stories about candidates getting a call fairly quickly when the decision is positive, so the silence started getting into my head.
Then, on 11th August, I finally got the call from the recruiter.
Unfortunately, it wasn't the call I was hoping for.
The recruiter told me that there were some concerns around my design depth.
My DSA performance was good, but it wasn't strong enough to overturn the concerns around my design performance, especially for an SDE II role.
And just like that, I got the rejection.
Final Thoughts
I'm not going to lie — this one hurt.
After spending weeks preparing, reading hundreds of interview experiences, working on LLD, practicing DSA, preparing LP stories, and then going through the entire loop, getting that call was honestly completely shattering.
There were definitely things I could have done better.
The first LLD round didn't go the way I wanted.
I spent too much time going deep into the HLD aspects instead of getting to the actual LLD implementation.
The LRU round also taught me that time management during an interview matters just as much as knowing the solution.
And ultimately, the feedback made it clear that I need to go deeper into system design for SDE II roles.
There is a lot to take away from this.
Sometimes, the things you really want don't always want you back.
But that's okay.
I'm not going to give up on this until the result goes in my favor.
For anyone interested, I had also written about my Google interview experience last year. Sharing it here as well:
Google Interview Experience 2025
Cheers!
Keep fighting. 🚀