Amazon SDE2 Virtual Onsite Interview Experience: 5 Rounds in One Day

I just finished my Amazon SDE2 Virtual Onsite (VO). Five rounds in one day, and honestly, my brain was completely empty afterward.

Looking back, I realized that I had prepared for the wrong thing. I spent a lot of time preparing for System Design, and that preparation definitely helped. But the round that pushed me closest to my limit was actually the Bar Raiser behavioral interview, especially the continuous follow-up questions.

Here is a detailed breakdown of all five rounds for anyone preparing for an Amazon SDE2 / L5 interview.

Round 1: Coding + Deliver Results

The round started with a behavioral question around Deliver Results. I was asked about a project where I had to deliver under significant time pressure.

The interviewer then went several levels deeper:

• How did you prioritize when the deadline was approaching?
• Did you ever sacrifice quality to meet a deadline?
• What did you learn from the situation?
• What would you do differently if you faced the same situation again?

This type of question is much harder than simply telling a good story. You need to be prepared for the third or fourth layer of follow-ups. Otherwise, it is very easy to run out of things to say.

Coding Questions

1. Task Scheduler Variant

Given tasks with a cooldown period, determine the minimum time required to complete all tasks. The solution uses a greedy approach.

2. Sliding Window Maximum

This was a classic LeetCode Sliding Window Maximum problem using a monotonic deque.

Both coding questions were around classic medium-level problems. However, the interviewer did not stop after the code was working. I was asked to explain the time and space complexity and walk through several edge cases.

At Amazon, finishing the code is not necessarily the end of the coding round. Be ready to explain why your solution works and what happens in unusual cases.

Round 2: Coding + Ownership

The behavioral question focused on Ownership: taking responsibility for a problem that technically was not part of your job.

One important lesson from this question is that you should not only explain what you took ownership of. The interviewer is often more interested in how you decided whether you should take ownership in the first place.

Be prepared to explain your decision-making process, the trade-offs you considered, and what happened after you got involved.

Coding Questions

1. LRU Cache

The interviewer followed up by asking how the design could be changed to support LFU Cache, and how the implementation could remain thread-safe in a concurrent environment.

2. Merge K Sorted Lists

Another classic problem involving multiple sorted linked lists. The key was being able to clearly explain the complexity and implementation trade-offs.

Round 3: OOP / Low-Level Design — Parking Lot

The third round was an Object-Oriented Design / Low-Level Design problem: design a parking lot system.

The system needed to support:

• Different vehicle types
• Parking spot allocation
• Payment and billing
• Checking available parking spaces

The main evaluation was not about how much code you could write. It was about whether your class design made sense and whether the system could be extended without requiring major changes.

I used the Strategy Pattern for the billing logic, and the interviewer seemed to respond positively to that design.

The follow-ups included:

• How would you support multiple floors?
• How would you handle different pricing rules?
• What if the billing rules changed based on time?
• How would you make the design easier to extend?

This is where the Open-Closed Principle (OCP) becomes more than a textbook concept. The interviewer wants to see whether your design can support new requirements without constantly modifying existing classes.

Round 4: System Design — URL Shortener

The System Design round was a classic URL Shortener design.

After clarifying the requirements, I proposed a read/write architecture where a new short URL generates a 7-character Base62 code, which is stored in a key-value store.

For reads, the request first goes through Redis and falls back to the database when there is a cache miss.

The interviewer then went deeper into several areas:

• 301 vs. 302 redirects
• Handling extremely popular or "hot" URLs
• Database sharding
• Shard routing strategies
• Read-heavy traffic patterns

I had prepared relatively well for System Design, so this round went smoothly. However, one thing I realized afterward is that System Design does not end when you finish presenting your architecture.

In many interviews, the follow-up questions are where a significant part of the evaluation happens. I had a few moments where I was slower than I wanted to be when responding to the deeper trade-off questions.

Round 5: Bar Raiser — The Hardest Round

The fifth round was the Amazon Bar Raiser interview, and by far the most difficult round of the day.

The Bar Raiser was a senior interviewer from another team. The behavioral follow-ups were significantly deeper than in the previous rounds.

Behavioral Questions

1. Disagreeing With Your Manager

I was asked about a situation where I strongly disagreed with a decision made by my manager.

The follow-ups focused on what happened after my proposal was rejected and whether I was able to execute a plan that I personally disagreed with.

2. Learning a New Technology Outside of Work

I was asked about a technology I learned purely out of personal interest.

The interviewer wanted to know how I learned it, why I chose it, and whether I eventually applied it to a real project.

3. Making a Decision With Incomplete Information

Another question focused on a decision I had made without having all the necessary information.

The interviewer asked about the outcome, what assumptions I made, and what I would change if I could do it again.

The important thing about this round is that the interviewer is not simply listening to your story. They are testing whether the logic behind the story is consistent.

Every answer can trigger another follow-up question, which can trigger another one. It feels almost like an endless chain of questions.

Coding Question

Maximum Product Subarray

This was the classic maximum product subarray problem. The key is to maintain both the maximum and minimum product ending at the current position, because a negative number can turn the smallest product into the largest one.

When encountering a negative value, the maximum and minimum states need to be swapped before updating them.

My Biggest Takeaways From the Amazon SDE2 Interview

Looking back, I think the biggest difference between Amazon SDE1 and SDE2 is not necessarily the difficulty of the coding questions.

The two biggest differences are System Design and Behavioral Interview depth.

1. System Design Is Mandatory

For SDE2, System Design is a core part of the interview. You need to be comfortable discussing scalability, caching, databases, partitioning, reliability, and trade-offs.

More importantly, you cannot stop after drawing a reasonable architecture. The interviewer will likely challenge individual components and ask why you made certain decisions.

2. Behavioral Questions Go Much Deeper

Amazon's Leadership Principles, especially Ownership and Deliver Results, can lead to very deep follow-up questions at the SDE2 level.

Saying "my team decided to do X" is often not enough. The interviewer wants to understand your personal judgment, your decisions, your mistakes, and your position.

3. Coding Is Usually Not the Biggest Trap

The coding questions were mostly around LeetCode Medium difficulty. With enough preparation, there was enough time to solve them.

The bigger challenge was being able to explain the solution clearly, analyze complexity, handle edge cases, and respond to follow-up questions without losing the thread.

How I Prepared for the Amazon SDE2 VO

One of the resources I used during my preparation was
InterviewShow.

In hindsight, I would spend even more time preparing behavioral stories than I originally did. For every major Amazon Leadership Principle story, I would prepare not only the main STAR answer but also the possible third- and fourth-level follow-ups.

If you are preparing for an Amazon SDE2 / L5 Virtual Onsite, don't just memorize your stories. Make sure you can defend every decision in those stories under pressure.

Final Thoughts

The biggest lesson from this interview was that Amazon SDE2 is less about solving hard coding problems and more about demonstrating engineering judgment.

Coding gets you through the basic technical bar. System Design shows whether you can think at a broader engineering level. But the Bar Raiser behavioral round can reveal whether your decisions, ownership, communication, and judgment actually match the expectations for an SDE2.

If I were preparing again, I would spend less time worrying about whether I can solve another random LeetCode Hard and more time practicing how to defend my decisions when an interviewer keeps asking, "Why?"