Amazon SDE Interview Questions 2026: Complete Guide with Answers

Amazon SDE Interview Process Overview

Amazon's SDE interview process is rigorous and structured. Understanding each stage is crucial for success. Amazon uses a bar raiser model where each interviewer independently evaluates your performance against the leadership principles and technical bar. You need to meet the bar in every round, not just on average.

Interview Stages

1. Online Assessment (OA): 2 coding problems, 70 minutes
2. Technical Phone Screen: 1-2 coding problems, 45 minutes
3. Onsite Loop: 4-5 rounds covering coding, system design, and behavioral

What Amazon Evaluates

Amazon does not just test your coding ability. They evaluate you on three dimensions: technical depth, leadership principle alignment, and cultural fit. Every answer you give in a behavioral round should map to at least one leadership principle. Every technical solution should demonstrate scalability and code quality. Interviewers submit feedback independently before the debrief to avoid groupthink.

Online Assessment (OA) Preparation

What to Expect

• 2 coding problems (Medium to Hard difficulty)
• 70 minutes total time
• Tests: DSA, problem-solving, code quality
• Some roles include a work simulation task with 2 short questions about prioritization and customer impact

Advanced OA Preparation Strategies

Week 1-2: Foundation Building
Practice 3-4 problems daily on LeetCode focusing on Amazon-tagged questions. Start with arrays, strings, and hash maps. These are the most common OA problem types. Target problems with acceptance rates above 40% but below 70% to find questions that are challenging but solvable.

Week 3-4: Pattern Recognition
Group problems by pattern: sliding window, two pointers, BFS/DFS, dynamic programming, and greedy algorithms. Amazon OA problems often test your ability to recognize which pattern applies quickly. Spend no more than 5 minutes deciding on an approach before coding.

Week 5-6: Timed Practice
Simulate real OA conditions. Set a 35-minute timer per problem. Practice on a plain text editor without syntax highlighting to mimic the OA environment. Record your solve time and accuracy rate.

Week 7: Full Simulation
Take 3-4 full practice OAs back-to-back. Build stamina for the 70-minute window. Review every wrong answer and understand why your approach failed.

Time Management During OA

A proven strategy is to allocate time as follows:

• Minutes 1-5: Read both problems, identify the easier one
• Minutes 5-35: Solve the first (easier) problem completely
• Minutes 35-65: Solve the second problem
• Minutes 65-70: Review both solutions, test edge cases

If you finish the first problem in 20 minutes, that is great. Use the saved time on the harder problem. Never spend more than 5 minutes on a problem you cannot crack. Move on and come back if time allows.

Common OA Problem Types

Arrays and Strings

// Example: Two Sum variations
int[] twoSum(int[] nums, int target) {
    Map<Integer, Integer> map = new HashMap<>();
    for (int i = 0; i < nums.length; i++) {
        int complement = target - nums[i];
        if (map.containsKey(complement)) {
            return new int[] { map.get(complement), i };
        }
        map.put(nums[i], i);
    }
    return new int[] {};
}

Amazon-specific pattern: You will often see variations like Three Sum, Subarray Sum Equals K, or finding pairs with a given difference. The hash map approach is the most frequently tested pattern for arrays.

Trees and Graphs

// Example: Level Order Traversal
List<List<Integer>> levelOrder(TreeNode root) {
    List<List<Integer>> result = new ArrayList<>();
    if (root == null) return result;
    Queue<TreeNode> queue = new LinkedList<>();
    queue.offer(root);
    while (!queue.isEmpty()) {
        int size = queue.size();
        List<Integer> level = new ArrayList<>();
        for (int i = 0; i < size; i++) {
            TreeNode node = queue.poll();
            level.add(node.val);
            if (node.left != null) queue.offer(node.left);
            if (node.right != null) queue.offer(node.right);
        }
        result.add(level);
    }
    return result;
}

Amazon-specific pattern: Binary search trees and graph traversal (BFS and DFS) appear in over 60% of OA sessions. Practice problems like Validate BST, Number of Islands, and Clone Graph.

Dynamic Programming

// Example: Climbing Stairs with Cost
int minCostClimbingStairs(int[] cost) {
    int n = cost.length;
    int[] dp = new int[n + 1];
    dp[0] = 0;
    dp[1] = 0;
    for (int i = 2; i <= n; i++) {
        dp[i] = Math.min(dp[i-1] + cost[i-1], dp[i-2] + cost[i-2]);
    }
    return dp[n];
}

Amazon-specific pattern: DP problems on Amazon OA usually involve optimization (min cost, max profit, longest subsequence). If you see a problem about minimizing or maximizing something with constraints, think DP first.

OA Tips

• Start with the easier problem to build confidence
• Test your solution with edge cases before submitting
• Write clean, readable code with proper variable names
• Optimize for time complexity if brute force is too slow
• Handle empty inputs, single elements, and maximum constraints
• Use descriptive variable names since code readability is evaluated
• Comment complex logic briefly but do not over-comment
• If stuck, consider whether the problem maps to a known pattern

Coding Interview Questions

Data Structures and Algorithms

Q1: Implement a LRU Cache

Design a data structure that follows the constraints of a Least Recently Used (LRU) cache.

Key Insight: Use a HashMap and Doubly Linked List for O(1) operations. The HashMap provides instant lookup while the doubly linked list maintains usage order.

class LRUCache {
    private int capacity;
    private Map<Integer, Node> map;
    private Node head, tail;

    class Node {
        int key, value;
        Node prev, next;
        Node(int k, int v) { key = k; value = v; }
    }

    public LRUCache(int capacity) {
        this.capacity = capacity;
        map = new HashMap<>();
        head = new Node(0, 0);
        tail = new Node(0, 0);
        head.next = tail;
        tail.prev = head;
    }

    public int get(int key) {
        if (!map.containsKey(key)) return -1;
        Node node = map.get(key);
        remove(node);
        addToHead(node);
        return node.value;
    }

    public void put(int key, int value) {
        if (map.containsKey(key)) {
            remove(map.get(key));
        }
        Node node = new Node(key, value);
        map.put(key, node);
        addToHead(node);
        if (map.size() > capacity) {
            Node lru = tail.prev;
            remove(lru);
            map.remove(lru.key);
        }
    }

    private void remove(Node node) {
        node.prev.next = node.next;
        node.next.prev = node.prev;
    }

    private void addToHead(Node node) {
        node.next = head.next;
        node.prev = head;
        head.next.prev = node;
        head.next = node;
    }
}

Follow-up discussion: Amazon interviewers will ask about thread safety. Mention that you can use Collections.synchronizedMap or ConcurrentHashMap for thread-safe access, and discuss trade-offs between read-write locks and atomic operations.

Q2: Merge K Sorted Lists

Merge k sorted linked lists and return it as one sorted list.

Key Insight: Use a min-heap to efficiently merge lists. The heap keeps track of the smallest element across all lists at all times.

public ListNode mergeKLists(ListNode[] lists) {
    PriorityQueue<ListNode> pq = new PriorityQueue<>((a, b) -> a.val - b.val);
    for (ListNode node : lists) {
        if (node != null) pq.offer(node);
    }
    ListNode dummy = new ListNode(0);
    ListNode curr = dummy;
    while (!pq.isEmpty()) {
        ListNode node = pq.poll();
        curr.next = node;
        curr = curr.next;
        if (node.next != null) pq.offer(node.next);
    }
    return dummy.next;
}

Time complexity: O(N log k) where N is the total number of nodes and k is the number of lists. This is optimal because you must touch every node at least once.

Q3: Word Break

Given a string s and a dictionary of words, determine if s can be segmented into a space-separated sequence of dictionary words.

Key Insight: Dynamic programming where dp[i] represents whether s[0:i] can be segmented.

public boolean wordBreak(String s, List<String> wordDict) {
    Set<String> dict = new HashSet<>(wordDict);
    boolean[] dp = new boolean[s.length() + 1];
    dp[0] = true;
    for (int i = 1; i <= s.length(); i++) {
        for (int j = 0; j < i; j++) {
            if (dp[j] && dict.contains(s.substring(j, i))) {
                dp[i] = true;
                break;
            }
        }
    }
    return dp[s.length()];
}

Amazon connection: This problem is directly relevant to Amazon search and product categorization systems where text needs to be parsed against known entities.

Q4: Find Median from Data Stream

Design a data structure that supports addNum and findMedian operations.

Key Insight: Use two heaps, a max-heap for the lower half and a min-heap for the upper half. Maintain them in balance so their sizes differ by at most one.

class MedianFinder {
    private PriorityQueue<Integer> maxHeap;
    private PriorityQueue<Integer> minHeap;

    public MedianFinder() {
        maxHeap = new PriorityQueue<>(Collections.reverseOrder());
        minHeap = new PriorityQueue<>();
    }

    public void addNum(int num) {
        maxHeap.offer(num);
        minHeap.offer(maxHeap.poll());
        if (minHeap.size() > maxHeap.size()) {
            maxHeap.offer(minHeap.poll());
        }
    }

    public double findMedian() {
        if (maxHeap.size() > minHeap.size()) {
            return maxHeap.peek();
        }
        return (maxHeap.peek() + minHeap.peek()) / 2.0;
    }
}

Why Amazon asks this: Real-time analytics dashboards at Amazon need to compute running statistics. This problem tests your ability to design for streaming data.

Q5: Top K Frequent Elements

Given an integer array nums and an integer k, return the k most frequent elements.

Key Insight: Use a frequency map combined with a min-heap of size k. This gives O(N log k) time.

public int[] topKFrequent(int[] nums, int k) {
    Map<Integer, Integer> freq = new HashMap<>();
    for (int n : nums) freq.merge(n, 1, Integer::sum);
    PriorityQueue<Integer> pq = new PriorityQueue<>((a, b) -> freq.get(a) - freq.get(b));
    for (int key : freq.keySet()) {
        pq.offer(key);
        if (pq.size() > k) pq.poll();
    }
    int[] result = new int[k];
    for (int i = 0; i < k; i++) result[i] = pq.poll();
    return result;
}

Amazon relevance: This pattern is used in Amazon's recommendation engine to surface trending products and in search ranking to identify frequently searched terms.

System Design Interview Questions

Q1: Design a URL Shortener

Requirements:

• Shorten URLs to 6-8 character codes
• Redirect short URLs to original
• Handle 100M URLs, 1B redirects/day

Key Components:

1. Hashing: Use base62 encoding or MD5 hash
2. Storage: Key-value store (DynamoDB, Redis)
3. Cache: Redis for hot URLs
4. Analytics: Track click counts

Deep Dive Points Amazon Interviewers Expect:

• How do you handle hash collisions? Use a counter suffix or regenerate with a different salt.
• How do you ensure availability? Use multi-region replication with DynamoDB global tables.
• How do you handle hot keys? Cache the top 1% of URLs in Redis with a TTL of 1 hour.
• What about URL expiration? Use a separate TTL table or lazy deletion with a background reaper.

Q2: Design a Rate Limiter

Requirements:

• Limit requests per user/IP
• Support different limits per endpoint
• Distributed system support

Algorithms:

1. Token Bucket: Tokens added at fixed rate, consumed per request. Good for bursty traffic.
2. Sliding Window: Count requests in time window. More accurate than fixed window.
3. Fixed Window: Simple counter with reset. Easiest to implement but has boundary burst issues.

Amazon-specific considerations:

• Rate limiting is critical for AWS API Gateway. Discuss how you would implement it at the edge using Lambda or at the application layer.
• Mention sticky sessions vs stateless design. Stateless with shared Redis is preferred for horizontal scaling.
• Discuss graceful degradation: what happens when the rate limiter itself fails? Use local fallback counters.

Q3: Design a Chat System

Requirements:

• Real-time messaging
• Support 1M concurrent users
• Message history
• Online presence

Architecture:

1. WebSocket Connections: For real-time messaging
2. Message Queue: Kafka for message ordering
3. Database: Cassandra for message storage
4. Cache: Redis for presence, recent messages

Amazon connection: This is directly relevant to Amazon Chime and internal communication tools. Discuss how you would handle message delivery guarantees (at-least-once vs exactly-once) and how you would implement read receipts.

Q4: Design a Product Search System

Requirements:

• Full-text search across millions of products
• Autocomplete suggestions
• Filter by category, price, rating
• Handle flash sales with traffic spikes

Key Components:

1. Search Index: Elasticsearch cluster with sharding
2. Autocomplete: Trie-based service with Redis caching
3. Ranking: Learning to rank model using click-through data
4. Availability: Read replicas, circuit breakers, graceful degradation

Deep Dive: Discuss how Amazon handles relevancy tuning. Mention A/B testing different ranking models and using click-through rate as a proxy for relevance. Talk about how you would handle a Prime Day traffic spike with 10x normal load.

Q5: Design a Notification System

Requirements:

• Send notifications via push, email, and SMS
• Support 100M users
• Handle preference management
• Ensure exactly-once delivery

Architecture:

1. Ingestion Layer: API Gateway with validation
2. Queue: SQS for decoupling and retry
3. Worker Pool: Lambda or ECS for processing
4. Delivery: SNS for fan-out, SES for email, direct provider APIs for SMS
5. Preference Store: DynamoDB for user preferences

Amazon-specific discussion: Mention how Amazon's own notification system handles package tracking updates. Discuss idempotency keys to prevent duplicate notifications and dead letter queues for failed deliveries.

Leadership Principles Questions

Amazon has 16 Leadership Principles. You do not need to memorize all 16, but you should have stories mapped to at least 8-10 of them. The most commonly tested ones are Customer Obsession, Ownership, Bias for Action, Dive Deep, and Deliver Results.

Customer Obsession

Q: Tell me about a time you went above and beyond for a customer.

STAR Answer:

• Situation: A key client reported a critical bug affecting their production system
• Task: I was responsible for resolving the issue within 24 hours
• Action: I immediately jumped on a call, identified the root cause, and deployed a hotfix. I also set up monitoring to prevent recurrence.
• Result: Client's system was restored in 4 hours. They extended their contract worth $500K.

Q: Describe a time you made a decision based on customer needs rather than business convenience.

STAR Answer:

• Situation: Our team wanted to delay a feature release to fix technical debt
• Task: Customers were waiting for the feature and had been promised a timeline
• Action: I proposed a phased release. Ship the core functionality on time, and deliver the polished version two weeks later.
• Result: Customer trust was maintained. The phased approach actually gave us better early feedback.

Ownership

Q: Describe a time you took ownership of a problem outside your scope.

STAR Answer:

• Situation: Our team's deployment pipeline was failing intermittently
• Task: While not my responsibility, it was blocking the team's productivity
• Action: I investigated the issue, found a race condition in the CI/CD config, and submitted a fix
• Result: Pipeline reliability improved from 85% to 99.5%, saving 10 hours/week of debugging

Q: Tell me about a time you took on something outside your area of responsibility.

STAR Answer:

• Situation: A junior engineer on another team was stuck on a database migration
• Task: I had deep experience with the database system they were using
• Action: I spent an afternoon pairing with them, reviewed their migration plan, and helped them identify a data loss risk they had missed
• Result: Migration completed successfully. The junior engineer later told me it was the most productive learning session of their quarter.

Bias for Action

Q: Tell me about a time you made a decision without having all the data.

STAR Answer:

• Situation: A production incident was affecting 15% of users, but the root cause was unclear
• Task: We needed to act quickly to stop the bleeding
• Action: I recommended rolling back the last deployment even though we were not 100% sure it was the cause. The rollback was safe and reversible.
• Result: Incident resolved in 20 minutes. Post-mortem confirmed the deployment was the trigger. We later added automated rollback detection.

Dive Deep

Q: Tell me about a time you had to dig deep to solve a complex problem.

STAR Answer:

• Situation: Production latency spiked to 5 seconds from 200ms
• Task: Find and fix the root cause before it impacted more users
• Action: I analyzed logs, traced requests through the system, and discovered a missing database index on a new query
• Result: Added the index, latency dropped back to 180ms. Created a runbook for future incidents.

Q: Describe a time you had to use multiple data sources to make a decision.

STAR Answer:

• Situation: We were deciding whether to migrate from MySQL to DynamoDB
• Task: I needed to provide a data-driven recommendation
• Action: I collected query patterns, measured read/write ratios, projected growth, and benchmarked both databases with our actual workload
• Result: I recommended a hybrid approach: DynamoDB for high-throughput tables, MySQL for complex joins. This reduced costs by 40%.

Deliver Results

Q: Tell me about a time you delivered results under a tight deadline.

STAR Answer:

• Situation: We had a compliance deadline in 3 weeks to add audit logging to all API endpoints
• Task: 50+ endpoints needed instrumentation
• Action: I designed a middleware-based solution that automatically logged all requests. This covered 90% of endpoints with a single implementation. The remaining 10% got custom handlers.
• Result: Completed in 2 weeks, ahead of deadline. The middleware approach became the standard for all teams.

Behavioral Question Bank

Prepare stories for these common themes. Each story should follow the STAR format and take 2-3 minutes to tell.

1. Conflict resolution: Disagreement with a teammate or manager. Focus on how you found common ground and moved forward.
2. Failure: A project that did not go as planned. Show what you learned and how you applied the lesson.
3. Ambiguity: Making decisions with incomplete information. Demonstrate your judgment and risk assessment.
4. Innovation: Improving a process or system. Quantify the impact whenever possible.
5. Mentorship: Helping others grow. Show genuine investment in others' success.
6. Deadline pressure: Delivering under tight constraints. Explain how you prioritized and what trade-offs you made.
7. Cross-team collaboration: Working across organizational boundaries. Show how you navigated different priorities.
8. Technical debt: Balancing speed vs quality. Show pragmatic decision-making.
9. Disagree and commit: A time you disagreed with a decision but supported it after voicing your concern.
10. Earn trust: A situation where you had to rebuild trust after a mistake or miscommunication.
11. Frugality: Achieving more with less. Show resourcefulness.
12. Insist on standards: A time you pushed back on a shortcut that would compromise quality.

Story Preparation Template

For each story, prepare:

• The situation in 2-3 sentences
• Your specific task and why it mattered
• 3-4 concrete actions you took
• Quantified results (percentages, dollar amounts, time saved)
• What you learned and how it changed your approach

Preparation Timeline

8-Week Plan

Detailed Daily Schedule

Weeks 1-2 (DSA Fundamentals):

• Monday-Friday: Solve 3 LeetCode problems (Easy-Medium). Focus on arrays, strings, linked lists.
• Saturday: Review all problems solved. Identify patterns.
• Sunday: Rest or light review of solutions.

Weeks 3-4 (DSA Patterns):

• Monday-Friday: Solve 3-4 Medium-Hard problems. Group by pattern: sliding window, two pointers, BFS/DFS, DP.
• Saturday: Timed practice. Solve 2 problems in 60 minutes.
• Sunday: Review weak patterns, redo failed problems.

Weeks 5-6 (System Design):

• Monday-Wednesday: Study one system design topic deeply (URL shortener, rate limiter, chat system).
• Thursday-Friday: Practice drawing architectures and explaining trade-offs aloud.
• Saturday: Mock system design with a friend or on Pramp.
• Sunday: Review and refine your system design framework.

Week 7 (Behavioral + Mock):

• Monday-Wednesday: Prepare 12-15 STAR stories covering all major leadership principles.
• Thursday-Friday: Do 2 mock behavioral interviews. Record yourself and review.
• Saturday: Full onsite simulation (4 rounds).
• Sunday: Review feedback, refine weak stories.

Week 8 (Full Mock Interviews):

• Monday-Wednesday: 2 full mock interviews per day (coding + behavioral).
• Thursday: Light review, focus on confidence building.
• Friday: Rest day. Light stretching, good sleep.
• Saturday/Sunday: Interview day or final review.

Common Mistakes and How to Avoid Them

Mistake 1: Not explaining your thought process
Amazon interviewers want to hear your reasoning. Do not silently code. Narrate your approach before writing code. Say things like: "I will use a hash map here because we need O(1) lookups" or "I am considering two approaches: one with sorting and one without."

Mistake 2: Ignoring edge cases
Always discuss and handle edge cases: empty inputs, single elements, null values, duplicates, maximum constraints. Amazon interviewers specifically look for this. Say: "Before I code, let me clarify the edge cases."

Mistake 3: Not connecting behavioral answers to Leadership Principles
Every behavioral answer should explicitly name the leadership principle you are demonstrating. Say: "This is an example of Ownership because..." This helps the interviewer map your answer to their evaluation rubric.

Mistake 4: Optimizing too early
Get a working solution first, then optimize. Jumping straight to an optimized approach often leads to bugs. Say: "Let me start with a brute force solution to make sure it works, then I will optimize."

Mistake 5: Giving vague behavioral answers
Avoid generalizations like "I always work hard." Instead, give specific examples with numbers. Say: "I reduced API response time by 40%" not "I improved performance."

Mistake 6: Not asking clarifying questions
Always ask clarifying questions before solving a coding or system design problem. This shows maturity and prevents you from solving the wrong problem. Ask about scale, constraints, and priorities.

Mistake 7: Running out of time on one problem
If you are stuck, verbalize what you have tried and ask for a hint. Interviewers are allowed to give hints. Getting stuck silently is worse than asking for help.

Tips from Successful Candidates

Tip 1: Practice aloud
Coding interview performance improves significantly when you practice speaking your thoughts. Record yourself solving problems and watch it back. You will catch filler words, long pauses, and unclear explanations.

Tip 2: Know your resume deeply
Every line on your resume is fair game for behavioral questions. If you listed a project, be ready to discuss challenges, decisions, and outcomes in detail.

Tip 3: Research the specific team
If you know which team you are interviewing for, research their products and challenges. Mentioning specific Amazon services in your answers shows genuine interest.

Tip 4: Use the BAR framework for behavioral questions

• Background: Set the context briefly
• Action: Describe what YOU did (not the team)
• Result: Share quantified outcomes

Tip 5: Prepare questions for the interviewer
Good questions to ask:

• What does success look like in this role in the first 90 days?
• What is the biggest technical challenge the team is facing?
• How does the team balance innovation with maintenance?

Tip 6: Manage your energy
The onsite loop is 4-5 hours of intense focus. Sleep well the night before. Eat a balanced meal before the loop. Bring water and a snack for breaks.

Tip 7: Follow up within 24 hours
Send a thank-you email to your recruiter within 24 hours. Reference specific topics from your conversations. This is not required but shows professionalism.

Further Reading

• SDE Interview Roadmap - Complete phase-by-phase preparation plan
• Behavioral Questions - STAR method deep dive
• Java Interview Questions - Java-specific preparation
• Java Mastery - Complete Java learning path
• System Design Guide - Framework for system design rounds