LeetCode Problems for Amazon Interviews

Amazon hires more software engineers than any other company on the planet. In a typical year, Amazon extends tens of thousands of SDE offers across teams ranging from AWS and Alexa to Prime Video and Robotics. That sheer volume means the leetcode amazon interview pipeline is one of the most standardized and well-documented in the industry — and that is actually good news for candidates.

Because Amazon runs so many interviews, the patterns are predictable. The same problem categories show up again and again. The same behavioral framework — Leadership Principles — shapes every single round. If you study the right problems and understand the format, you can walk in with a significant edge over candidates who are grinding randomly.

This guide breaks down the exact Amazon interview format, the most frequently tested LeetCode patterns and problems, how Leadership Principles factor into coding rounds, and a focused 4-week prep plan. Whether you are targeting SDE I, SDE II, or SDE III, the core preparation strategy is the same.

The Amazon SDE interview process has three major stages, and understanding each one helps you allocate your prep time efficiently. The pipeline starts with an online assessment, progresses to a phone screen, and culminates in the onsite loop — which Amazon now conducts virtually for most positions.

The online assessment (OA) is typically two coding problems with a 70-minute time limit. These problems are LeetCode easy-to-medium difficulty and lean heavily on arrays, strings, and basic tree operations. You also complete a work style assessment that maps to Leadership Principles. The OA is pass/fail — you need to solve both problems with correct and efficient solutions to advance.

The phone screen is a single 45-60 minute round with one coding problem (LeetCode medium) and 10-15 minutes of behavioral questions. The interviewer shares a collaborative coding environment and evaluates your problem-solving process as much as your final answer.

The onsite loop consists of 4-5 rounds conducted over a single day. Two rounds are coding (LeetCode medium to hard), one is system design (SDE II and above), and one or two are behavioral with a coding component. Every single round includes Leadership Principles evaluation. One interviewer is designated the Bar Raiser — an engineer from a different team whose job is to maintain Amazon hiring standards.

Amazon interview data from thousands of candidate reports reveals clear pattern preferences. Unlike Google, which skews toward graph theory and dynamic programming, Amazon coding interviews favor practical patterns that reflect the kind of engineering work their teams do daily — processing large datasets, managing distributed systems, and optimizing for scalability.

Arrays and hashing dominate Amazon interviews. Problems involving hash maps for O(1) lookups, frequency counting, and two-sum-style pattern matching appear in roughly 30 percent of all Amazon coding rounds. This makes sense — AWS services process billions of requests, and efficient data lookup is fundamental to that scale.

Tree and graph traversal is the second most common category, appearing in about 25 percent of rounds. BFS and DFS problems — especially on binary trees — are Amazon staples. Number of Islands, Binary Tree Level Order Traversal, and Word Ladder show up with remarkable consistency because they model real problems like network traversal and dependency resolution.

Dynamic programming and greedy algorithms round out the top tier, each appearing in about 15 percent of rounds. Amazon tends to favor medium-difficulty DP problems like Coin Change and Word Break rather than the harder DP problems you might see at Google. Greedy problems like Merge Intervals and Meeting Rooms test your ability to find efficient solutions without over-engineering.

Sliding window and two pointers appear less frequently but are critical for the online assessment, where time pressure makes recognizing these patterns essential for fast solutions.

These 15 problems appear most frequently in Amazon SDE interview reports. They are not the only problems Amazon asks, but mastering them covers the core patterns and gives you the problem-solving frameworks you need for any variation the interviewer throws at you.

Two Sum (#1) is the most commonly reported Amazon problem across all levels. It tests hash map usage for O(n) lookups and is often used as a warm-up in phone screens. LRU Cache (#146) is a favorite for onsite rounds because it combines hash maps with doubly-linked lists and tests your ability to implement a real data structure from scratch.

Number of Islands (#200) is the quintessential BFS/DFS problem at Amazon. It models real-world scenarios like cluster detection and connected component analysis. Merge Intervals (#56) tests sorting and interval merging — a pattern that comes up in scheduling systems, log processing, and resource allocation.

Word Ladder (#127) tests BFS on an implicit graph and is one of the harder problems on this list. Minimum Window Substring (#76) is a classic sliding window problem that Amazon asks at the SDE II level and above. Both problems reward candidates who can clearly articulate their approach before coding.

The remaining problems round out the most critical patterns: Longest Substring Without Repeating Characters (#3), Binary Tree Level Order Traversal (#102), Course Schedule (#207), Word Break (#139), Coin Change (#322), Meeting Rooms II (#253), Trapping Rain Water (#42), Search in Rotated Sorted Array (#33), and Serialize and Deserialize Binary Tree (#297).

What makes Amazon interviews unique is that Leadership Principles (LPs) are evaluated in every round — including the coding rounds. At most companies, behavioral and technical interviews are separate. At Amazon, your interviewer is simultaneously assessing your code and evaluating whether you demonstrate principles like Ownership, Dive Deep, and Deliver Results.

During coding rounds, this means how you communicate matters as much as whether you get the optimal solution. When you encounter a problem, talk through your thought process. Explain why you chose a hash map over a brute-force approach. Discuss the time-space tradeoff of your solution. If you hit a dead end, explain your reasoning for pivoting — this demonstrates Bias for Action and Learn and Be Curious.

Amazon interviewers are trained to ask follow-up questions that probe LP alignment. After you solve a problem, expect questions like: "How would you test this?" (Insist on the Highest Standards), "What if the input scale increased 100x?" (Think Big), or "How would you explain this solution to a non-technical stakeholder?" (Earn Trust). Prepare for these by practicing the STAR method — Situation, Task, Action, Result — even for your technical explanations.

The Bar Raiser specifically looks for candidates who raise the overall talent level. They are not looking for perfection — they want to see growth mindset, intellectual curiosity, and the ability to handle ambiguity. If you get stuck on a problem, the Bar Raiser is watching whether you stay calm, ask clarifying questions, and methodically work toward a solution.

Time management on the online assessment is the most common failure point. You have 70 minutes for two problems, but many candidates spend 50 minutes on the first problem and rush the second. Practice solving LeetCode mediums in 30 minutes or less so you have buffer time. Run through the OA simulation on your own — set a timer, use a plain text editor, and solve two problems back-to-back.

When explaining tradeoffs during coding rounds, always frame your decisions in terms that Amazon values: scalability, customer impact, and operational simplicity. Instead of just saying "I chose a hash map for O(1) lookups," say "I chose a hash map because it scales linearly with input size, which matters when processing high-throughput request data." This maps your technical choice to a real engineering context.

For SDE II and above, system design is a full round and carries significant weight. Amazon system design questions focus on their own domain — design a recommendation engine, design a package tracking system, design an API rate limiter. Study the building blocks of AWS services since many design questions implicitly reference them: DynamoDB for key-value storage, SQS for message queuing, S3 for object storage.

Mock interviews are non-negotiable for Amazon prep. The combination of coding plus behavioral evaluation in the same round is unusual, and you need practice switching between solving a problem and articulating your thought process in LP terms. Do at least 3-4 mock interviews where your partner asks LP follow-ups during the coding portion.

This focused plan assumes 1.5 to 2 hours of daily study and is designed specifically for Amazon interview prep. The key insight is that Amazon interviews are more predictable than other FAANG companies, so targeted practice outperforms random grinding every time.

Week 1 is foundation week. Complete the top 15 problems listed above, focusing on understanding the pattern behind each one rather than memorizing the solution. Use YeetCode flashcards to drill the pattern names and approaches — when you see "find connected components," your brain should immediately think BFS/DFS with visited tracking. Spend 20 minutes daily on LP STAR stories.

Week 2 focuses on depth. Pick the three weakest patterns from your Week 1 practice and solve 5 additional problems in each category. If you struggled with sliding window, solve Longest Repeating Character Replacement (#424), Permutation in String (#567), and similar problems. Continue daily flashcard review with YeetCode to lock in the patterns from Week 1.

Week 3 is mock interview week. Do 3 full mock interviews — one OA simulation (2 problems, 70 minutes), one phone screen simulation (1 problem plus behavioral, 60 minutes), and one onsite-style round (1 hard problem with LP follow-ups). Record yourself if possible and review your communication patterns.

Week 4 is review and confidence building. Revisit every problem you solved in the first three weeks using YeetCode spaced repetition. Focus on problems you could not solve in under 25 minutes — those are your highest-risk areas. Do one final mock interview 2-3 days before the real thing, then rest. You have put in the work.