Amazon Coding Interview: Top Questions + Leadership Principles

Amazon's interview is uniquely demanding because it tests two completely different things in parallel: your coding ability and your alignment with 16 Leadership Principles. Candidates who prepare for the coding side without preparing for LP questions are often surprised when behavioral rounds carry equal weight.

Amazon's Interview Process

A standard Amazon SDE loop:

1. Online assessment (70–90 min) — 2 coding problems + a work simulation test
2. Phone screen (60 min) — 1–2 coding problems
3. On-site / "Virtual Loop" — 4–5 rounds, each lasting 60 minutes:
   • 2–3 coding rounds
   • 1–2 bar raiser rounds (combined coding + LP)
   • Sometimes a system design round

The Bar Raiser is unique to Amazon — a trained interviewer from a different team whose job is to maintain the hiring bar across the company. Bar Raisers have veto power. They often push harder on edge cases, complexity, and behavioral depth.

Amazon's 16 Leadership Principles (and How They Show Up)

Amazon's LPs are more than corporate values — they're evaluation criteria. Every behavioral question at Amazon maps to one or more LPs. For practice questions targeting each principle, see our Amazon behavioral interview questions guide. Review Amazon's official Leadership Principles page to understand each principle in their own words.

You don't need to memorize definitions — you need 12–15 strong STAR stories that collectively cover the most-asked LPs.

Most-asked LPs (prepare these first): Customer Obsession, Ownership, Bias for Action, Dive Deep, Deliver Results, Disagree and Commit.

Amazon's Coding Problems

Amazon's coding questions tend to be:

• Heavier on trees and graphs than Meta or Google
• More focused on practical scenarios ("Design a function that...") rather than pure algorithm puzzles
• Often two problems per round (similar to Meta)
• Sometimes pulled from their internal systems as inspiration (distributed queues, recommendation systems, order processing)

High-frequency Amazon problem categories:

The "LP Question" Before the Coding Problem

At Amazon, many coding rounds start with a 10–15 minute behavioral question before the coding problem. This is not a warmup — it's an evaluated component.

Common opening structure:

• Interviewer: "Tell me about a time you took ownership of something that wasn't your responsibility."
• Candidate: 4–5 minute STAR answer
• Interviewer: Probe questions (2–3 min)
• Then: transition to coding problem

The coding problem gets 35–40 minutes in a 60-minute round. Time your behavioral answer accordingly.

What Amazon Specifically Values

Beyond correct code, Amazon looks for:

• Simplicity: Amazon's "Invent and Simplify" LP shows up in code too — overly complex solutions get flagged
• Production mindset: "What happens when this fails?" is a common follow-up
• Customer framing: Talking about user impact alongside technical decisions reads positively
• Ownership language: "I designed," "I decided," "I shipped" — not "we" for individual contributions

How to Prepare for Amazon

Coding preparation

1. Master trees, graphs, DP, and heap problems — these are disproportionately common
2. Practice in 60-minute blocks (longer rounds than Meta's 45-minute blocks)
3. After each problem, ask yourself: "What would break at 10x scale?" Amazon interviewers often ask this

LP preparation

1. Write down 15 STAR stories covering your career
2. Tag each story with the LPs it demonstrates
3. For each story, prepare for: "Tell me more about your decision-making process" and "What would you do differently now?"
4. Practice out loud — LP answers that haven't been spoken aloud feel very different from ones that have only been written
5. Use our Amazon behavioral interview questions list to test yourself against real question patterns

Combined practice

Run mock interview sessions where you answer one LP question (4–5 min) followed immediately by a 35-minute coding problem. The context-switching is a specific skill Amazon's format requires.

Practice at Amazon's Format

InterviewSkool's mock interviews include the combined LP + coding format that Amazon runs. Practice the full session experience, not just the coding portion.

Start an Amazon-style mock interview →

Frequently Asked Questions

Amazon Interview Process Flowchart

flowchart TD
    A["Online Application"] --> B["Online Assessment"]
    B --> C{"Pass OA?"}
    C -->|"Yes"| D["Phone Screen - 60 min"]
    C -->|"No"| E["Reapply in 6 months"]
    D --> F{"Pass Phone Screen?"}
    F -->|"Yes"| G["Virtual Loop / Onsite - 5 rounds"]
    F -->|"No"| E
    G --> H["Round 1: Coding + LP"]
    H --> I["Round 2: Coding + LP"]
    I --> J["Round 3: Bar Raiser"]
    J --> K["Round 4: System Design or Coding"]
    K --> L["Round 5: Hiring Manager"]
    L --> M["Debrief: All interviewers convene"]
    M --> N{"Decision?"}
    N -->|"Hire"| O["Offer Extended"]
    N -->|"No Hire"| E
    N -->|"Borderline"| P["Additional loop possible"]

Amazon's Leadership Principles Decision Tree

When answering behavioral questions, use this decision tree to identify which LP the question maps to:

Then: Structure your answer using the STAR method

Amazon's Leadership Principles Deep Dive

Beyond knowing all 16 LPs, here are the five most heavily weighted ones and exactly how to prepare for them.

1. Customer Obsession

Amazon starts with the customer and works backwards. This is the single most tested LP.

What interviewers want to hear:

• You identified a customer need before being asked
• You sacrificed short-term efficiency for long-term customer trust
• You used data to understand what customers actually wanted (not what they said they wanted)

Example STAR structure:

Situation: Our checkout flow had a 23% drop-off rate, but the product team had no plans to address it. Task: I was responsible for backend payments, but I wanted to fix this. Action: I ran a heat-map analysis, discovered the issue was a confusing address validation step, and proposed removing it for domestic orders. I presented data to the PM and got buy-in. Result: Drop-off fell to 11%, saving an estimated $2.4M annually. This became the standard checkout flow.

2. Ownership

Amazonians think long-term and act on behalf of the entire company, not just their team.

What interviewers want to hear:

• You took initiative outside your job description
• You followed through end-to-end, including the parts that "weren't your job"
• You didn't pass the problem to someone else

Red flag answers: "I told my manager," "I escalated it," "I filed a ticket."

3. Dive Deep

Amazon values leaders who operate at all levels and stay connected to the details.

What interviewers want to hear:

• You went past surface-level symptoms to find root causes
• You used metrics, logs, or data to validate your hypothesis
• You resisted the urge to apply a quick fix without understanding the problem

Strong example topic: Debugging a production issue where the obvious cause was wrong, and you traced it through multiple layers.

4. Deliver Results

Amazon is a results culture. This LP tests whether you can prioritize and drive outcomes despite constraints.

What interviewers want to hear:

• You set clear milestones and hit them
• You made trade-off decisions when resources were limited
• You delivered something that mattered, not just something that shipped

5. Disagree and Commit

Amazon values vocal disagreement followed by full commitment once a decision is made.

What interviewers want to hear:

• You voiced a clear, data-driven objection
• You respected the decision-making process
• You committed fully after the decision was made, even though you disagreed

Weak answer: "I disagreed but just went along with it." Strong answer: "I presented three alternatives with trade-off analysis. The team chose option B. I committed fully and helped ship it, and it succeeded."

Amazon Code Examples

Example 1: Two Sum (Array / Hash Map)

A classic Amazon warmup problem. Amazon often pairs this with a follow-up about scale.

Problem: Given an array of integers and a target, return the indices of two numbers that add up to the target.

def two_sum(nums, target):
    seen = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], i]
        seen[num] = i
    return []

function twoSum(nums, target) {
  const seen = {};
  for (let i = 0; i < nums.length; i++) {
    const complement = target - nums[i];
    if (complement in seen) {
      return [seen[complement], i];
    }
    seen[nums[i]] = i;
  }
  return [];
}

Complexity: O(n) time, O(n) space. Amazon follow-up: "What if the array is sorted?" — Use two pointers for O(1) space. "What if there are multiple valid pairs?" — Return all of them.

Example 2: Number of Islands (Graph / BFS)

Extremely common at Amazon. Tests your ability to model grid traversal as a graph problem.

Problem: Given a 2D grid of '1's (land) and '0's (water), count the number of islands.

from collections import deque

def num_islands(grid):
    if not grid:
        return 0
    
    rows, cols = len(grid), len(grid[0])
    count = 0
    
    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == '1':
                count += 1
                grid[r][c] = '0'
                queue = deque([(r, c)])
                while queue:
                    row, col = queue.popleft()
                    for dr, dc in [(0, 1), (0, -1), (1, 0), (-1, 0)]:
                        nr, nc = row + dr, col + dc
                        if 0 <= nr < rows and 0 <= nc < cols and grid[nr][nc] == '1':
                            grid[nr][nc] = '0'
                            queue.append((nr, nc))
    
    return count

function numIslands(grid) {
  if (!grid.length) return 0;
  const rows = grid.length, cols = grid[0].length;
  let count = 0;

  for (let r = 0; r < rows; r++) {
    for (let c = 0; c < cols; c++) {
      if (grid[r][c] === '1') {
        count++;
        const queue = [[r, c]];
        grid[r][c] = '0';
        while (queue.length) {
          const [row, col] = queue.shift();
          for (const [dr, dc] of [[0,1],[0,-1],[1,0],[-1,0]]) {
            const nr = row + dr, nc = col + dc;
            if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && grid[nr][nc] === '1') {
              grid[nr][nc] = '0';
              queue.push([nr, nc]);
            }
          }
        }
      }
    }
  }
  return count;
}

Complexity: O(m * n) time, O(min(m, n)) space for BFS queue. Amazon follow-up: "What if the grid is too large to fit in memory?" — Process in chunks, or use union-find with streaming data.

Example 3: LRU Cache (Design / Hash Map + Doubly Linked List)

A favorite Amazon system design coding problem. Tests data structure design and production thinking.

class Node:
    def __init__(self, key=0, val=0):
        self.key = key
        self.val = val
        self.prev = None
        self.next = None

class LRUCache:
    def __init__(self, capacity):
        self.cap = capacity
        self.cache = {}
        self.head = Node()
        self.tail = Node()
        self.head.next = self.tail
        self.tail.prev = self.head

    def _remove(self, node):
        node.prev.next = node.next
        node.next.prev = node.prev

    def _add_to_front(self, node):
        node.next = self.head.next
        node.prev = self.head
        self.head.next.prev = node
        self.head.next = node

    def get(self, key):
        if key in self.cache:
            node = self.cache[key]
            self._remove(node)
            self._add_to_front(node)
            return node.val
        return -1

    def put(self, key, value):
        if key in self.cache:
            self._remove(self.cache[key])
        node = Node(key, value)
        self.cache[key] = node
        self._add_to_front(node)
        if len(self.cache) > self.cap:
            lru = self.tail.prev
            self._remove(lru)
            del self.cache[lru.key]

Complexity: O(1) for both get and put. Amazon follow-up: "What if this needs to be thread-safe?" — Discuss locking strategies. "What if the cache is distributed?" — Discuss consistent hashing and replication.

Example 4: Coin Change (Dynamic Programming)

A standard DP problem that Amazon uses to test problem decomposition.

def coin_change(coins, amount):
    dp = [float('inf')] * (amount + 1)
    dp[0] = 0
    
    for i in range(1, amount + 1):
        for coin in coins:
            if coin <= i and dp[i - coin] + 1 < dp[i]:
                dp[i] = dp[i - coin] + 1
    
    return dp[amount] if dp[amount] != float('inf') else -1

function coinChange(coins, amount) {
  const dp = new Array(amount + 1).fill(Infinity);
  dp[0] = 0;

  for (let i = 1; i <= amount; i++) {
    for (const coin of coins) {
      if (coin <= i && dp[i - coin] + 1 < dp[i]) {
        dp[i] = dp[i - coin] + 1;
      }
    }
  }

  return dp[amount] === Infinity ? -1 : dp[amount];
}

Complexity: O(amount * coins.length) time, O(amount) space. Amazon follow-up: "What if you also need to return the actual coins used?" — Track the parent pointer in DP. "What if the coin set changes dynamically?" — Discuss incremental recomputation.

What Amazon Interviewers Look For

A score of 4 means "strong hire, would want on my team." A score of 2 is "lean no hire." You need consistent 3s and 4s across rounds.

Real Amazon Interview Walkthrough

Here's a realistic walkthrough of what a single 60-minute Amazon round looks like:

Minutes 0-5: Introduction The interviewer introduces themselves and explains the format: "We'll start with a behavioral question, then move to a coding problem."

Minutes 5-15: Behavioral Question Interviewer: "Tell me about a time you had to make a critical technical decision under time pressure." You respond with a STAR answer (~4-5 minutes), then the interviewer probes:

• "What would have happened if you had chosen the other option?"
• "How did you communicate the risk to stakeholders?"
• "What did you learn from that experience?"

Minutes 15-20: Problem Setup Interviewer presents the coding problem:

"Given a binary tree, return the right side view of the tree — meaning, for each level, return only the rightmost node. For example, if the tree is:

    1
   / \
  2   3
   \   \
    5   4

The right side view would be [1, 3, 4]."

Minutes 20-25: Clarification and Approach You ask clarifying questions:

• "Can the tree have duplicate values?"
• "What if the tree is empty? Should I return an empty array?"
• "Is this a binary search tree or just a binary tree?"

Then you describe your approach: "I'll use BFS level-order traversal. For each level, I'll take the last node. Time complexity O(n), space complexity O(w) where w is the max width."

Minutes 25-45: Coding You write the solution while thinking aloud:

from collections import deque

def rightSideView(root):
    if not root:
        return []
    
    result = []
    queue = deque([root])
    
    while queue:
        level_size = len(queue)
        for i in range(level_size):
            node = queue.popleft()
            if i == level_size - 1:
                result.append(node.val)
            if node.left:
                queue.append(node.left)
            if node.right:
                queue.append(node.right)
    
    return result

Minutes 45-50: Testing and Follow-up You trace through your example manually. The interviewer asks: "What if we wanted the left side view instead?" You modify the code quickly. Then: "What if the tree has 10 million nodes and we can't fit it in memory?" You discuss streaming/chunked approaches.

Minutes 50-55: Complexity Analysis You explain: "Time is O(n) since we visit every node once. Space is O(w) for the queue, worst case O(n/2) ≈ O(n) for a complete tree."

Minutes 55-60: Wrap-up The interviewer asks if you have questions about the team, the role, or Amazon in general. You ask about the team's technical challenges and growth area.

Common Amazon Interview Mistakes

1. Ignoring the Behavioral Opening

Many candidates treat the opening LP question as a throwaway warmup. It's scored equally with the coding problem. A weak behavioral answer sets a negative frame for the entire round.

2. Not Thinking Aloud Enough

Amazon interviewers evaluate your communication process. Long silences while coding are penalized. Even saying "I'm considering whether to use a hash map or a sorted array here" is better than silence.

3. Over-Engineering the Solution

Amazon's "Invent and Simplify" LP applies to code too. Jumping to a segment tree when a simple hash map works signals over-engineering. Start simple, then optimize if asked.

4. Forgetting Edge Cases

Amazon interviewers expect you to handle:

• Empty inputs (null root, empty array, empty string)
• Single-element inputs
• Very large inputs (scale discussion)
• Duplicate values
• Negative numbers (where applicable)

5. Weak STAR Stories

The most common LP mistake is telling stories that are too vague or too old. "At my last company, we improved performance" is weak. "In Q3 2024, I identified a bottleneck in our payment processing pipeline that was causing 12% of transactions to timeout, and I redesigned the retry logic to reduce failures to 0.3%" is strong.

6. Not Asking Questions at the End

Amazon interviewers notice when you don't ask questions. It signals low curiosity or low interest. Prepare 2-3 genuine questions about the team's technical stack, challenges, or growth plans.

Amazon vs Google vs Meta: Interview Comparison

Level-Specific Preparation

SDE-1 (L4)

• Coding bar: Medium-level LeetCode problems. Two-sum, linked list operations, basic trees.
• System design: Rarely asked. If asked, it's basic (design a URL shortener).
• LP depth: 2-3 minute STAR answers are sufficient. Focus on internships, coursework, or early career projects.
• What to focus on: Clean code, basic data structures, clear communication.

SDE-2 (L5)

• Coding bar: Medium-hard. Trees, graphs, DP, sliding window. Often two problems in one round.
• System design: May be asked. Expect medium-complexity designs (design a rate limiter, design a notification system).
• LP depth: 4-5 minute STAR answers. Need evidence of impact beyond your immediate team.
• What to focus on: Production thinking, scaling considerations, ownership examples.

Senior SDE-3 (L6)

• Coding bar: Hard. Complex graph problems, advanced DP, optimization challenges. Still two problems possible.
• System design: Almost always asked. Expect large-scale designs (design Amazon's order processing system, design a global CDN).
• LP depth: Deep probing. Interviewers want org-level impact, multi-team influence, and technical vision.
• What to focus on: Ambiguity handling, strategic thinking, cross-team influence, long-term technical decisions.

Principal Engineer (L7)

• Coding bar: Rarely the focus. May be asked to code but weight is minimal.
• System design: Heavy. Expect company-wide architecture discussions.
• LP depth: Critical. Must demonstrate industry-level impact, technical strategy, and org-wide leadership.
• What to focus on: Business impact, technical vision, organizational influence.

Amazon's Bar Raiser: What It Is and How to Impress Them

The Bar Raiser is the most critical person in your Amazon interview loop.

What is a Bar Raiser?

• A trained interviewer from a different team than the one you're applying to
• Has veto power — can block a hire even if all other interviewers say yes
• Attends a calibration session where they review all feedback
• Their job is to ensure every new hire raises the average quality of the team

How Bar Raisers Evaluate Differently

Bar Raisers look beyond the specific round they're in. They're assessing:

1. Would I want this person on MY team? (not just the hiring team)
2. Does this person demonstrate consistent excellence across both coding and behavioral?
3. Is this person better than 50% of current employees at this level?

How to Impress a Bar Raiser

During the coding portion:

• Handle every edge case proactively
• Discuss trade-offs between approaches before coding
• Ask about scale: "What if we have 100M users?"
• Show production awareness: "How would we monitor this in production?"

During the behavioral portion:

• Use specific metrics and outcomes
• Show self-awareness: "In retrospect, I should have..."
• Demonstrate growth: "After that experience, I changed my approach to..."
• Connect to customer impact, not just technical achievement

Red flags that trigger a Bar Raiser veto:

• Correct code but no discussion of complexity
• Inability to handle follow-up questions
• Vague behavioral answers without measurable outcomes
• Lack of curiosity about the team or role
• Dismissiveness toward edge cases or testing

Quick Reference Cheat Sheet

Must-Know Data Structures for Amazon

Time Complexity Quick Reference

Amazon-Specific Patterns to Recognize

1. Two-pointer on sorted data — for sorted array problems, always consider this first
2. BFS level-order — for tree level problems, word ladder, rotten oranges
3. DFS with visited set — for island problems, clone graph, paths
4. Sliding window — for substring/subarray with constraint problems
5. Monotonic stack — for next greater element, trapping rain water
6. Topological sort — for course schedule, task scheduling
7. Binary search on answer — for minimum/maximize optimization problems

STAR Method Template for Amazon LPs

Situation: [1-2 sentences — set the context]
Task: [1 sentence — your specific responsibility]
Action: [3-4 sentences — what YOU did, using "I" not "we"]
Result: [1-2 sentences — measurable outcome with numbers]

30-Day Amazon Prep Timeline