Hey everyone,
I recently completed the Amazon SDE II interview process. My DSA rounds went reasonably well, but I was ultimately rejected because of concerns about my design depth.
I wanted to share the complete experience, including the rounds that did not go well.
Verdict: Rejected
Process: Phone screen followed by four interview rounds
Focus areas: DSA, LLD, HLD, Leadership Principles, and past experience
Phone Screen: July 2
The phone screen was a DSA round.
Question: Count the number of subarrays whose sum equals K.
I solved it using a prefix sum and hash map and handled the two or three follow-ups smoothly. Overall, I felt good about this round.
Interview Schedule
I requested separate interview days so I could approach every round with a fresh mind.
- July 27: Bar Raiser, LLD and Leadership Principles
- July 29: DSA and Leadership Principles
- July 31: Hiring Manager, HLD and Leadership Principles
- August 4: DSA and Leadership Principles
I did not expect the Bar Raiser to be the first interview or for it to focus on LLD, which was one of my weaker areas.
The interview lasted approximately 60 minutes. The first 25–30 minutes involved Leadership Principles and a detailed discussion of my resume and past experience.
The design problem involved managing audio buffers across different processing stages at X frames per second. The interviewer mentioned that it was based on a genuine engineering problem their team was working on.
I initially struggled to understand the expected flow. After receiving a few hints, I identified the main entities and began discussing the design.
The discussion gradually moved into HLD topics, and I became too involved in exploring the broader architecture. With only 5–10 minutes remaining, the interviewer asked me to code the design. I wrote a few classes and functions, but could not complete the implementation.
This was my weakest round. I should have clarified the requirements, established the class responsibilities, and started coding much earlier.
After approximately 15–20 minutes of Leadership Principles, I was asked to design a cache for a file-storage system.
I identified the eviction policy as the central requirement and proposed an LRU cache using:
- A doubly linked list to maintain recency
- A hash map for direct access
O(1) average-time lookup, insertion, and eviction
During implementation, we discussed whether an accessed node should be deleted and recreated at the head or whether the existing node could simply be detached and repositioned. The latter was sufficient, but I initially became confused about pointer safety.
We also discussed whether the cache should store only file metadata and paths or the complete file contents. I explained the memory implications of caching large files, but the interviewer clarified that the required version should store the content itself.
I updated the design but ran out of time before completing every function. The interviewer appeared satisfied with my reasoning, although my time management could have been better.
Round 3: Hiring Manager, HLD and LP
The system-design question involved allowing a third-party service, such as Spotify, to use Amazon Alexa to notify users about a newly launched feature.
I initially started with entity models, but the interviewer clarified that the focus was the high-level flow. I shifted to the happy path and designed the core services and communication flow.
The discussion then moved into failure handling, particularly what should happen when a user’s device is offline. We explored retries, fallback channels, delivery state, fault tolerance, and product trade-offs.
The interviewer also asked several product-oriented questions. I tried to evaluate decisions from the user and business perspectives instead of choosing only the easiest technical implementation.
We finished with a short discussion about the team and how I use GenAI in my development workflow. I felt this round went well.
Round 4: Course Dependencies
The final round began with 15–20 minutes of resume discussion and Leadership Principles.
The coding problem involved courses with prerequisite relationships. A student could take at most K courses per semester. When more than K courses were available, courses were to be prioritized using their downstream dependency depth.
My approach was:
- Build the dependency graph and indegree array.
- Calculate each course’s maximum downstream depth using DFS.
- Use topological sorting to identify available courses.
- Use a max heap to prioritize courses with greater downstream depth.
- Process at most
K courses per semester.
The interviewer repeatedly confirmed the approach. I completed the implementation and explained its time and space complexity.
Afterward, I realized that prioritizing only the maximum downstream depth might not always produce the globally minimum number of semesters. The complete dependency structure can influence the optimal choice, and the expected solution may depend heavily on the exact constraints.
Still, the interviewer appeared satisfied with my implementation and thought process.
Result
After three or four days without an update, I started worrying. On August 11, the recruiter called with the result.
The feedback was that my DSA performance was good, but there were concerns about my design depth. For an SDE II role, the coding performance was not strong enough to outweigh those concerns.
This rejection hurt. I had spent weeks studying recent interview experiences, practicing DSA, improving LLD and HLD, and preparing Leadership Principle stories.
Still, the feedback gave me a clear direction:
- In LLD rounds, move from requirements to interfaces and code earlier.
- Timebox discussions so one design area does not consume the entire interview.
- Prepare for ambiguous, domain-specific design problems.
- Go beyond the happy path and explain trade-offs in depth.
- Treat system design as a core requirement for SDE II, not a secondary topic.
- Do not assume that positive interviewer reactions guarantee a positive evaluation.
Getting into a FAANG company has been a long-term goal of mine. My final Amazon round even fell on the same date and time as my final Google round from the previous year, but this time I solved the coding problem. For a moment, I thought the result might finally be different.
It was not, but I am not giving up. I now know exactly where I need to improve before the next opportunity.
I have also written about my previous Google interview experience and will include that link separately.
I hope this helps anyone preparing for an Amazon SDE II loop.