Amazon SDE II Interview Complete Experience: From Online Assessment to Offer

Background

Let me start with my background: I did both my bachelor's and master's in Computer Science in China, then spent 4 years as a backend developer at a mid-sized Chinese tech company. My tech stack was primarily Java and Go, working on microservice architectures, distributed systems, and message queues on a daily basis. Honestly, things were going fine at my old company, but I always felt a ceiling looming overhead. Plus, I'd always wanted to work abroad, so I started looking into Amazon opportunities.

In September 2025, I spotted an SDE II opening for Amazon's Shanghai office on LinkedIn, and there was also a headcount for Seattle. I hesitated for a bit, then decided to apply to both — figuring Shanghai would be great, but Seattle was the dream. About two weeks after submitting my resume, I got an email from a recruiter saying I'd passed the resume screen and they wanted me to take the OA (Online Assessment).

I'll be honest — preparing for the Amazon interview took way longer than I expected. There was algorithm prep, system design practice, but what really caught me off guard was the weight of Amazon Leadership Principles (LP) behavioral interviews. Almost every round had LP questions woven in, which is something you almost never encounter in Chinese tech company interviews. I spent about 6 weeks preparing. Here's my complete walkthrough of the entire process, in chronological order.

Online Assessment (OA, 2 Problems, 120 Minutes)

After receiving the OA link, the system gave me 120 minutes to complete 2 algorithm problems. The OA was on HackerRank, and I could choose my language — I went with Java.

Problem 1: Log Aggregation and Analysis

The problem was roughly: given a server log file where each entry contains timestamp, serverId, responseTime, and statusCode fields, implement a function that calculates the average response time for each server within a specified time window, then returns the results sorted by average response time in descending order. If two servers have the same average, sort by serverId ascending.

This wasn't too hard — essentially a group-by aggregation + sorting problem. I used a HashMap to group by serverId, calculated the average response time for each server, then defined a custom Comparator for sorting. Finished in about 15 minutes, and all test cases passed.

Problem 2: Task Scheduler with Dependencies

This was a variant of the classic LeetCode 621: given a list of tasks and a cooldown period n, find the minimum time to complete all tasks. But this version added an extra constraint — some tasks have dependencies on others and can only execute after their prerequisite tasks are done.

The dependency handling stumped me for a while. I first used topological sort to process the dependencies and determine execution order constraints, then applied a greedy strategy to schedule the tasks. Honestly, I didn't nail the approach right away — I had to sketch it out on paper for several minutes before it clicked. The final code was fairly long, around 40+ lines, and I passed 80% of the test cases — two edge cases weren't handled properly, and I ran out of time to debug them.

OA Result: Three days later, I received an email from the recruiter saying I'd passed the OA. They scheduled the virtual onsite interviews — 4 rounds spread across two days.

Round 1: LP Behavioral + Algorithm (About 55 Minutes)

My interviewer was an SDE III who'd been at Amazon for 5 years. He was Indian-American with a fairly heavy accent, but his pace was moderate and communication was smooth enough.

LP Section (About 20 Minutes)

He started with two LP questions:

Question 1: Tell me about a time when you went above and beyond for a customer. (LP: Customer Obsession)

I'd prepared for this one. I talked about a time at my previous company when we were working on a B2B project and a client came to us with an urgent data migration request that wasn't in the current sprint scope. I volunteered to work through the weekend, finished the migration script and tested it by Sunday, and delivered it Monday morning. The client was extremely satisfied and ended up renewing their contract. I used the STAR method, emphasizing why the customer needed this and how my actions directly impacted customer satisfaction.

Question 2: Tell me about a time when you had to make a decision without having all the information you needed. (LP: Bias for Action)

For this one, I described a production incident — I got paged at 2 AM with alerts showing the database connection pool was exhausted, but there weren't enough logs to pinpoint the root cause. Based on my experience, I suspected slow queries were causing connection leaks, so I made the call to implement rate limiting and circuit breaking first, then investigate. My hunch was right — service was restored in 15 minutes. The interviewer followed up with "What if your judgment had been wrong?" I said I'd ensure the degradation strategy itself was safe and reversible, then quickly validate the hypothesis.

Algorithm Section (About 30 Minutes)

Problem: Design a data structure that supports insert, delete, and getRandom, all in O(1) time complexity.

This is LeetCode 380, which I'd practiced before. The HashMap + ArrayList approach — on insert, add the element to the end of the list and record its index in the map; on delete, swap the target element with the last element in the list, remove the last element, and update the map index. After writing the code, the interviewer walked me through a few test cases, then asked about thread safety — what if multiple threads operate concurrently? I suggested using ReentrantLock or CopyOnWriteArrayList. He nodded and didn't push further.

Overall, this round felt solid — LP answers were smooth, and the algorithm didn't trip me up.

Round 2: System Design (About 55 Minutes)

The interviewer was a Senior SDE, Chinese-American, working in Amazon's AWS division. This round was pure system design — no LP questions.

Problem: Design a URL Shortener (similar to bit.ly)

This is a classic system design question, but the interviewer went deeper than I expected. I followed the standard system design framework:

1. Requirements Clarification: I asked about the read/write ratio (interviewer said 10:1, read-heavy), whether custom aliases were needed, whether analytics were required, and QPS estimates. After the interviewer provided clear answers, I moved on to design.

2. API Design: Defined two endpoints — createShortUrl(longUrl, customAlias?) and getLongUrl(shortUrl).

3. Core Approach: I proposed two methods for short URL generation — base62 encoding and MD5 hash truncation. The interviewer asked me to compare the tradeoffs. I analyzed that base62 is more readable but requires a global counter (a bottleneck in distributed environments), while MD5 hashing doesn't need coordination but has collision risks. I ultimately chose a pre-generated batch ID approach: use DynamoDB's atomic counter to batch-allocate ID ranges, then encode locally with base62.

4. Storage Layer: Used DynamoDB for the mapping table with shortUrl as the partition key. When the interviewer asked about caching, I suggested ElastiCache (Redis) for hot short URLs with LRU eviction.

5. Scalability: Discussed horizontal scaling through additional partitions and read replicas.

Where I Struggled: The interviewer asked something I hadn't prepared for — "What if a short URL suddenly becomes a hotspot (say a celebrity shares it)? How do you prevent cache stampede?" I thought for a moment and suggested request coalescing — let only one concurrent request hit the DB while others wait for the result. When pressed on the implementation, I mentioned using a concurrency marker (like AtomicBoolean), but honestly, my explanation was pretty hand-wavy. This was clearly a weak point in my preparation.

Overall, this round was decent, but the cache stampede question definitely exposed a gap in my system design preparation.

Round 3: LP Behavioral + Algorithm (About 55 Minutes)

The interviewer was an SDE II who'd been at Amazon for 3 years. He was white American, very friendly, and the overall vibe of this round was quite relaxed.

LP Section (About 20 Minutes)

Question 1: Tell me about a time when you disagreed with a colleague's technical approach. How did you handle it? (LP: Have Backbone; Disagree and Commit)

I talked about a tech selection disagreement with a colleague — he wanted RabbitMQ, I advocated for Kafka. I laid out Kafka's advantages in our use case (high throughput, persistence, replayable consumption) while acknowledging RabbitMQ's strengths in low-latency scenarios. We ended up doing a benchmark comparison, and the data supported my proposal — the team went with Kafka. The interviewer followed up: "What if the final decision hadn't been your approach?" I said, "Disagree and Commit — I'd fully execute the team's decision without passive resistance."

Question 2: Tell me about a time when you delivered a result under a tight deadline. (LP: Deliver Results)

I described a situation during a major shopping festival (similar to Black Friday) where our team's order service needed to ship a new feature within 3 days. I broke down the tasks, implemented non-core logic behind feature toggles (turned off initially), shipped the critical path first, then gradually enabled the rest. We delivered half a day early with zero production incidents.

Algorithm Section (About 30 Minutes)

Problem: Given a binary tree, find all root-to-leaf paths where the sum of node values equals a given targetSum. Return all qualifying paths.

LeetCode 113 — classic DFS backtracking. I quickly wrote the recursive solution. The interviewer asked me to explain the time complexity — I said worst case O(N * H), where N is the number of nodes and H is the tree height (because each path needs to be copied). He then asked what to do if the tree is extremely large and the recursion stack overflows. I suggested converting to an iterative approach with an explicit stack, or limiting the maximum depth. This round went smoothly overall.

Round 4: LP Behavioral + Algorithm (About 55 Minutes)

The interviewer was a Principal Engineer who'd been at Amazon for 8 years. He had a very commanding presence. This was by far the most stressful round for me.

LP Section (About 25 Minutes — the deepest LP probing of all rounds)

Question 1: Tell me about a time when you took ownership of a problem that wasn't technically your responsibility. (LP: Ownership)

I described a cross-team incident — the frontend team reported API timeouts, but the root cause was a database query issue on our team's side. Even though the frontend team came to me first, I could have easily redirected them to file a ticket with the DBA team. Instead, I chose to investigate myself, found a slow query missing an index, added the index and optimized the SQL, and resolved it in 30 minutes. The interviewer pushed back: "Do you think that was really your responsibility?" I said, "In Amazon's context, Ownership means seeing a problem and solving it, not passing it off to someone else."

Question 2: Tell me about a time when you had to learn something new quickly to solve a problem. (LP: Learn and Be Curious)

I talked about a project that required gRPC, which I had zero experience with. I spent a weekend reading the official documentation and example code, and by Monday I was able to write proto definitions and server/client code. The interviewer followed up: "What do you think is the biggest challenge when learning a new technology?" I said, "Not the syntax — it's understanding the design philosophy behind it and knowing when it's the right tool for the job."

Follow-up (the hardest LP question of the entire interview): The interviewer said, "You mentioned you added an index to solve the slow query. What if that index caused other problems, like slower writes or increased storage? How would you handle that?"

This question caught me off guard for a few seconds. I said I'd evaluate the index's impact in the staging environment first, looking at metrics like write latency increases and storage growth, then review with the DBA team. If the impact was acceptable, I'd proceed with the deployment; if not, I'd consider alternative optimization approaches (like query rewriting or database sharding). The interviewer seemed reasonably satisfied with this answer, though his expression was hard to read.

Algorithm Section (About 25 Minutes)

Problem: Design an LRU Cache that supports get and put operations, both in O(1) time complexity.

LeetCode 146 — HashMap + doubly linked list. I know this one cold and finished the code in about 10 minutes. But then the interviewer added a follow-up: How would you implement a thread-safe LRU Cache?

This follow-up threw me a bit. I proposed two approaches: first, a coarse-grained lock (simple but poor performance), and second, segmented locking (similar to ConcurrentHashMap's approach — divide the cache into multiple segments, each with its own lock). The interviewer asked me to write pseudocode for the segmented approach. I sketched out a rough framework, but some details were shaky — like how to determine the number of segments and how to handle resizing. The interviewer didn't push further, just said "interesting approach."

After this round, I had mixed feelings. The LP follow-ups were intense, and the algorithm follow-up wasn't fully nailed. This was definitely the most uncertain round of the four.

Complete List of Interview Questions

Here's a summary of all the questions I encountered during the Amazon SDE II interview, organized by round:

Online Assessment (OA)

Problem 1: Log Aggregation and Analysis
Key Topics: HashMap group-by aggregation, custom sorting
Difficulty: Medium

Problem 2: Task Scheduler with Dependencies
Key Topics: Topological sort + greedy scheduling
Difficulty: Medium-Hard

Round 1: LP Behavioral + Algorithm

LP1: Customer Obsession — Going above and beyond for a customer
LP2: Bias for Action — Making decisions with incomplete information
Algorithm: Insert Delete GetRandom O(1)
Key Topics: HashMap + ArrayList composite data structure design
Difficulty: Medium

Round 2: System Design

Design a URL Shortener
Key Topics: Distributed ID generation, DynamoDB storage design, caching strategy, cache stampede prevention
Difficulty: Medium-Hard

Round 3: LP Behavioral + Algorithm

LP1: Have Backbone; Disagree and Commit — Handling technical disagreements
LP2: Deliver Results — Delivering under tight deadlines
Algorithm: Path Sum II (Binary Tree Path Sum)
Key Topics: DFS backtracking
Difficulty: Medium

Round 4: LP Behavioral + Algorithm

LP1: Ownership — Taking ownership beyond your responsibility
LP2: Learn and Be Curious — Quickly learning new technologies
Follow-up: Boundaries and trade-offs of Ownership
Algorithm: LRU Cache + Thread-Safety Follow-up
Key Topics: HashMap + doubly linked list, concurrency control (segmented locking)
Difficulty: Medium (original) / Hard (follow-up)

Key Takeaways and Advice

About 5 business days after the interview, the recruiter called to let me know I'd received an offer — SDE II in Seattle, with a total compensation package that exceeded my expectations. Looking back on the entire process, here's my advice for anyone preparing for Amazon interviews:

1. LP isn't just a formality — it's the core of Amazon's interview
I used to think LP behavioral questions were just going through the motions, but the interviewers dug deep and followed up on every detail. I recommend preparing at least 6-8 stories from different scenarios, each covering 2-3 LP principles, organized using the STAR method. Pay special attention to quantifying your impact — "improved response time by 30%" is far more convincing than "improved response time."

2. Algorithm problems are around LeetCode Medium difficulty, but prepare for follow-ups
Amazon's algorithm questions won't be extremely hard, but interviewers almost always add follow-ups — thread safety, space optimization, edge cases, etc. When practicing, don't just aim for AC. Understand the variants and extensions of each data structure.

3. System design should reflect Amazon's tech stack preferences
Mentioning AWS services like DynamoDB, ElastiCache, and CloudWatch during the interview earns bonus points. I'm not saying you should force them in — but if you're familiar with the AWS ecosystem and naturally incorporate these components in your design, interviewers will see you as a better fit.

4. Interviews are a two-way street — stay authentic
My answers to the LP follow-ups in Round 4 weren't perfect, but they were all based on real experiences and genuine thinking. Amazon interviewers value authenticity — fabricated stories can't withstand deep probing. Rather than memorizing templates, take the time to thoroughly review your own real project experiences.

FAQ

Q1: How many rounds are there in an Amazon SDE II interview?
Typically, it's OA + 4 rounds of virtual onsite. Of the 4 rounds, 1 is usually pure system design and 3 are LP + algorithm. Some candidates may get an additional bar raiser round, but I didn't encounter one in my interview.

Q2: How important are Amazon LP behavioral interviews really?
Extremely important. There's a saying at Amazon that "LP is 50% of the interview." While that's not an exact weight, my experience was that LP and technical skills are weighted almost equally. If your LP answers are weak, you can be rejected even if you ace all the algorithms. I recommend studying all 16 Amazon Leadership Principles thoroughly and preparing at least 1-2 stories for each one.

Q3: Can you pass the OA without a perfect score?
Yes. I only passed 80% of the test cases on my second OA problem and still moved forward. Amazon cares more about your problem-solving approach and code quality than raw pass rates. Of course, if you're only passing half the test cases on both problems, it might be a stretch.

Q4: Can I answer LP questions in Chinese during the interview?
If you're interviewing for the Shanghai office, some interviewers may be Chinese-speaking and you could communicate in Chinese. But for the Seattle office, interviewers will almost exclusively be English-speaking. I recommend preparing and answering entirely in English. Even if the interviewer is Chinese, if they ask in English, you should respond in English.

Q5: How long does it typically take from interview to offer?
In my case, I got the result 5 business days after the interview. But from what I understand, Amazon's debrief meeting usually happens within 1-2 weeks after the interview, and the recruiter notifies you afterward. If you haven't heard back after two weeks, it's fine to proactively follow up via email.