Amazon Software Engineer Interview Process

Amazon grades its Leadership Principles in almost every round. A typical hour opens with 20 to 30 minutes of principle questions and leaves 25 to 30 for the technical problem, so the most common failure is running out of time, not missing the algorithm. At the debrief a Bar Raiser from outside the hiring team weighs that evidence alongside coding and design, and strong code does not offset thin stories. The online assessment now includes an hour of AI-assisted repository work, and design questions reach phone screens and new-grad loops.

This guide breaks down each stage of the Amazon Software Engineer interview, what interviewers evaluate in each round, and how to prepare, with questions candidates were actually asked.

Verified: Based on 117 candidate-reported interview experiences, primarily from 2026 Q1 through 2026 Q3, cross-checked against recent public accounts.

Amazon Software Engineer interview process

Amazon hires Software Development Engineers (SDEs) team by team, so interviewers usually come from the hiring team and problems follow its domain. The skeleton is an online assessment for most early-career candidates, one to four phone screens, and a loop of three to five hour-long rounds; the whole process takes from about five weeks to more than six months.

SDE I loops (interns and new graduates) run two to four rounds weighted toward coding and object-oriented design, some in person over two days with travel covered. SDE II adds system design and often skips the assessment; SDE III loops carry two or more design rounds.

Here's what the interview process can look like:

• Recruiter call: Confirms location, relocation and timeline and outlines the rounds.
• Online assessment (most intern, new-grad and SDE I/II candidates): About 40 minutes of algorithms, 60 minutes of AI-assisted repository work, then untimed work-simulation and work-style sections.
• Phone screens (one to four): 45 to 60 minutes, half Leadership Principles and half coding or small design in an editor that does not run code.
• Coding interviews (two or three): Hour-long loop rounds pairing principle questions with one or two problems.
• Low-level design interview (usually one): A two-sentence prompt turned into classes and working code.
• System design interview (SDE II and above, sometimes earlier): A distributed-systems discussion from the team's domain.
• Bar Raiser interview: An hour of behavioral depth with a trained interviewer from another team.
• Hiring manager interview: Motivation, metrics and generative-AI questions plus a lighter technical segment.

Tip: Plan every technical segment as a 25-minute problem: two minutes of plan, a working baseline in code, then improvements described aloud. Candidates who finished a careful data model but not the core logic were rejected even with the right approach.

Online assessment

The assessment is emailed after a resume screen; the link nominally expires in seven days, but recruiters have extended it by up to a month on request. It has up to four parts: about 40 minutes of one or two auto-graded algorithm problems, about 60 minutes of AI-assisted repository work, an untimed work simulation ranking responses to email scenarios, and an untimed work-style survey.

Algorithm problems come from recurring families: prefix sums on a circle (drone hubs on a ring, redistributing products), greedy merging so each value forms one contiguous block, heap simulations, and placing one extra delivery center on a grid with multi-source BFS plus binary search. A sparse-segment window with coordinates up to a billion is a known trap: one candidate's O(n) prefix array failed most tests on memory.

The repository task uses a small Django, Spring Boot, Node.js or C++ project with about six failing tests. Bugs are small: a record never persisted, a 401 where a 403 belongs, a missing URL setting, an inverted comparison, a stale variable. Some variants ask for a feature instead, such as review moderation that flags a user after three violations. The assistant explains the selected file but will not write fixes, and sometimes did not work at all.

Interviewers evaluate:

• Correctness at scale: Hidden tests include large inputs, so an approach that exceeds time or memory limits scores as wrong.
• Reading constraints: Value ranges, coordinate bounds and the wrap-around edge on a ring decide the intended solution.
• Debugging method: Running the tests first and tracing back from the failing assertion instead of reading the codebase top to bottom.
• Judgment in the simulation: Protecting testing near a launch, escalating early and gathering context outscore the fastest option.

Practice timed medium problems on arrays, heaps and grids, and rehearse fixing failing tests in an unfamiliar Django or Spring Boot project inside an hour.

Note: A perfect score is not required. Candidates advanced with some of the six tests still failing, while those who stalled had sunk the hour into one bug. Leave a few minutes to commit and push your changes, which at least one version required.

Sample questions for the online assessment

Here are some questions reported by recent candidates:

• Given non-overlapping segments of bags holding a fixed amount each, with indices up to a billion, find the most money in any k consecutive bags without building the array.

• Add at most one delivery center to a grid so that the largest distance from any cell to its nearest center is minimized.

• Fix a movie-watchlist app so that add, remove and lookup persist correctly and return the right HTTP status codes.

• Max Money from K Consecutive Bags

• Delivery-Center Grid — Minimum Inconvenience

• Drone Delivery on a Hub Ring — Minimum Travel

• Debug a Movie DB Watchlist Full-Stack Project

Phone screens

Screens run 45 to 60 minutes; internal transfers reported three that felt like a full loop. Each opens with 20 to 30 minutes of principle questions, then 25 to 30 minutes of coding in a shared editor that does not run code. The problem is usually one medium with layered follow-ups: course-schedule variants, merging sorted arrays in place then descending then unsorted, or finding a linked-list cycle and then breaking it. A large minority get a scenario or small design instead: a hashmap with no library support, Minesweeper, or a waitlist that seats a party of eight ahead of a party of two. Those who advanced usually heard back the next day.

Interviewers evaluate:

• Finishing inside the window: A complete, dry-run solution in 25 minutes; a half-built class hierarchy counts against you.
• Adapting to follow-ups: Changing sort order, breaking the cycle or handling a stream without starting over.
• Clarifying scenario prompts: Whether events repeat, whether progress only grows, which table sizes exist.
• Story specifics: When you knew a deadline would slip, whom you told and what data you used.

Rehearse medium problems in a plain editor without autocomplete, finishing each in 25 minutes including your own test cases.

Note: The recruiter's description of a screen is often wrong. Candidates told to expect pure coding got a library-system schema design, and two rejected candidates ran out of time on an event router and a stream detector they had not expected.

Sample questions for the phone screens

Here are some questions reported by recent candidates:

• Flag a book as abusive when more than 20% of its reading events jump to the final 5% from a user who never passed 10%, with counters updated concurrently.

• Build a Java service skeleton that parses JSON events, evaluates field filters and routes each match to named queues.

• Given services and their dependencies, return every service that fails when a set of services is taken offline.

• Abusive Books in Reading Event Stream

• Event Filter & Queue Routing Service

• Service Shutdown / Topological Sort

Coding interviews

The loop has two or three coding rounds of about 60 minutes, each opening with principle questions and then one or two problems, mostly easy to medium with occasional unmodified hard ones; one candidate got a hard problem with 15 minutes left. About half are custom scenarios: an out-of-order package receiver reporting the consecutive run and the gaps, a file-search API with substring and size filters and a question about symbolic links, a cache for traffic that peaks by time zone. Follow-ups push for a better bound ("can this be linear?"), memory, concurrency and streaming input. Treat each scenario as a small service: interface first, then bodies.

Interviewers evaluate:

• Optimal complexity when asked: A brute-force sliding-window maximum with no route to the deque version cost one candidate the round.
• Using every constraint: Package weights limited to 0 to 9 turn a sort into one counting pass, and interviewers wait to see if you notice.
• Self-testing: Candidates who wrote their own boundary cases were consistently credited.
• Stability under silence: Some interviewers say almost nothing; a candidate who rewrote a correct approach into a wrong one was rejected.

Practice topological sort, heaps, sliding windows, tries and LRU-style caches until each takes under 20 minutes, then their streaming variants.

Sample questions for the coding interviews

Here are some questions reported by recent candidates:

• Packages arrive with IDs in any order; report the end of the consecutive run starting at 0 and the missing IDs below the maximum.

• Pay a target amount with points from several programs at different rates, using the fewest points without exceeding any balance.

• Decide whether packages weighing 0 to 9 can be ordered so each adjacent pair sums to less than 10, then make it linear.

• Out-of-Order Package Receiver

• Minimum-Point Redemption Across Programs

• Package Weight Rearrangement

• Maximum Frequency Stack

Low-level design interview

Most loops include one object-oriented design round, some two. The prompt is about two sentences; you extract requirements, define classes and write enough code to run the core path in roughly 30 minutes. Reported prompts include a pizza ordering system, a cinema ticket price calculator, a deck with in-place shuffle and suit-ordered sort, a locker system, and splitting or merging database partitions around a size threshold. One new-grad round banned native collections: build a queue from linked nodes with constant-time operations, then add delete and remove-duplicates.

Interviewers evaluate:

• Requirement extraction: Asking about capacities, formats and ties before modeling anything.
• Entity boundaries: Separating a book title from a physical copy, or a pricing rule from the ticket it prices.
• Extension points: A strategy or decorator wherever new sort orders, formats or add-ons are hinted.
• Working code, not just diagrams: The core method runs end to end before time is up.

Practice turning a two-line prompt into an interface, three classes and a tested core method within 30 minutes.

Note: A list of if-statements is a failing answer even when it works. A candidate who handled partition split-and-merge with conditional checks, after spending most of the round clarifying, believed that round decided the rejection; a small class model with a pluggable policy was expected.

Sample questions for the low-level design interview

Here are some questions reported by recent candidates:

• Implement a queue with constant-time enqueue and dequeue from linked nodes only, then add delete of a value and removal of all duplicates.

• Price a cinema ticket from format, showtime, seat tier and add-ons so that new options need no edits to existing classes.

• Design a single-machine pub-sub system that delivers higher-priority messages in a topic first.

• Manual Queue Implementation

• Pub-Sub Messaging System

• Employee Total-Cost Object Model

System design interview

SDE II loops include one system design round and senior loops two or more; a hiring manager once asked for a web crawler in 20 minutes. It is a whiteboard conversation of 30 to 60 minutes. Prompts come from the interviewer's domain rather than the popular list: ride-hailing location ingestion, database failover with read replicas and split-brain handling, file-sharing permissions, seller image upload, product search by price and category, and a distributed cron scheduler. A mid-level candidate with no machine-learning background was asked to design a model training and deployment platform.

Interviewers evaluate:

• Customer framing first: Users, the experience that must not break, and stated assumptions before any schema.
• Justified storage choices: Several concrete reasons per choice, such as consistency for stock levels, transactions and indexing.
• Failure handling you raise yourself: Queue-decoupled notifications, idempotent sync APIs, conflict resolution.
• Rigor at senior levels: A staff-level candidate was rejected for a design that worked but lacked numbers and failure modes.

Practice designs from Amazon's own domains, opening each with a customer-facing requirements pass.

Note: An SDE II candidate who did well on coding was rejected after designing a multi-device e-book reader. The candidate went deep on APIs, caching, schemas and sync flows, and realized afterward that the round expected the customer experience, explicit assumptions and high-level trade-offs first.

Sample questions for the system design interview

Here are some questions reported by recent candidates:

• Design an e-book reader where one account reads a book on several devices, works offline and never lets one device overwrite another's progress.

• Design ingestion for high-frequency driver location updates and nearby-driver queries.

• Design a microservice that receives notifications and stays low-latency through sudden spikes.

• Design an Offline Multi-Device E-Book Reader

• Ride-Hailing System Design (Uber)

• Design a Product Image Upload Pipeline for Sellers

• Accept Notification Bursts With Low Latency

Bar Raiser interview

The Bar Raiser is an experienced interviewer from another team, trained to judge whether a candidate raises the average of the team. The round is usually an hour of behavioral questions, often held apart from the loop, from the day before to a month later; senior Bar Raisers have also asked for a priority queue from scratch. Expect three or four principles, each followed several layers down: dive deep, critical feedback, disagree and commit, root-cause analysis. One candidate counted 17 principle questions across a four-hour loop.

Interviewers evaluate:

• Ownership of specific actions: "I" statements with tools, dates and decisions, not team summaries.
• Depth under follow-up: The third "why" still has an answer; rehearsed outlines collapse there.
• Honest misjudgment: A real mistake dissected, including the signal that changed your mind.
• Results with numbers: Latency, adoption or time saved, and what you would change now.

Prepare 8 to 12 recent stories, each tagged with two or three principles, and rehearse their follow-up layers out loud.

Tip: On disagree-and-commit questions the grade turns on what you did after committing. A candidate who did not reopen the debate but mitigated the specific risk they had raised was credited; stories that stop at "I disagreed" are not.

Sample questions for the Bar Raiser interview

Here are some questions reported by recent candidates:

• Walk through a significant technical decision, the alternatives you rejected, and whether you would make it again.

• Describe a time you found an issue no one else had noticed: how you isolated it and why your first hypothesis was wrong.

• Tell me about a time you disagreed with a manager, committed anyway, and what happened next.

• Leadership Principles Standard Set

• Answer Dive Deep and Ownership in LP interview

• Demonstrate leadership under disagreement

Hiring manager interview

The manager's round leans behavioral, with about 30 minutes of technical work: an easy-to-medium problem, a deliberately vague rate limiter, or a whiteboard of a past project. Common questions are why Amazon, the weakness you are working on, and the metrics behind your impact. Generative AI is a standing theme: how you use it, how you noticed its output was wrong, and how you would test AI-generated code.

Interviewers evaluate:

• Self-awareness: A real weakness with changes already made, not a disguised strength.
• AI judgment: Concrete validation steps and a failure you caught.
• Metrics literacy: Numbers attached to the impact you claim.
• Coachability: Responding well when the manager redirects your approach mid-problem.

Prepare one generative-AI story that includes a failure and its fix, and a weakness story with evidence of improvement.

Sample questions for the hiring manager interview

Here are some questions reported by recent candidates:

• How did you realize output from a generative AI tool was not good enough, and what did you do?

• What do you most need to improve, and what have you changed so far?

• Implement a rate limiter from a vague description, then say what could replace your sliding-window deque.

• GenAI Usage (How / Failure / Tradeoff)

• Evaluating Generative AI Use and Accuracy

• Own a Mistake with Real Consequences

How Amazon levels and evaluates Software Engineer candidates

Each interviewer writes feedback independently against assigned principles and the target level's technical bar. A debrief run by the Bar Raiser, who has an effective veto, follows, and the Bar Raiser and hiring manager settle the outcome. Evidence is pooled: candidates who solved an LRU cache cleanly were still rejected when another round fell short, and one who thought the manager round went badly got an offer.

The target level is set before the loop and the bar moves with it; at SDE II and above, rejections concentrate in design. Team matching usually follows the offer, though some new graduates matched first and were interviewed by the hiring team itself. Amazon aims to decide within about five business days; reported waits ranged from two hours to just over a week. Candidates rejected after a full loop were recently told to wait one year before reapplying, not the six months many expected.

How to prepare for the Amazon Software Engineer interview

1. Budget for the split hour: Practice each problem as a 25-minute exercise in a plain editor, with your own test cases.
2. Write 8 to 12 tagged stories: Cover ownership, dive deep, disagree and commit, a missed deadline, critical feedback and a misjudgment, with metrics, dates and rejected alternatives.
3. Prepare a generative-AI story with a failure in it: Nearly every stage asks how you validate generated code.
4. Rehearse the repository task: Fix failing tests in a small Django or Spring Boot app in under an hour, starting from the test output.
5. Learn the assessment's problem families: Circular prefix sums, contiguous-block merging, sparse segments that must not be materialized, and multi-source BFS with binary search.
6. Turn two-sentence prompts into working classes: Include an extension point and a running core method, and build one structure without native collections.
7. Open every system design with the customer: State users, assumptions and trade-offs before APIs and schemas, and raise failure handling yourself.
8. Prepare every screen for all three formats: The recruiter's description of a round is often inaccurate.

About the Amazon Software Engineer role

Amazon SDEs own services end to end: design documents, code, tests, deployment and on-call. Teams are small and independent, owning services behind well-defined APIs, and the same Leadership Principles shape design reviews and promotions. Since January 2025 corporate staff work in the office five days a week.

Amazon hires Software Engineers across most of the company. Teams include:

• Amazon Web Services: Compute, storage, databases, networking and managed services.
• Worldwide Amazon Stores: Search, catalog, checkout, payments and seller tools.
• Operations and logistics: Fulfillment, transportation, delivery routing and inventory.
• Devices and Services: Alexa, Echo, Kindle, Fire TV and their cloud backends.
• Amazon Ads and Prime Video: Ad serving and measurement, and streaming platforms.
• Amazon Leo: The satellite broadband network formerly called Project Kuiper.

Software Engineer experience and education requirements

New-grad SDE I postings ask for a bachelor's or higher in a STEM field (completed or in progress), one general-purpose language such as Java, Python, C++ or Go, and data structures and algorithms experience. SDE II postings ask for three or more years of non-internship development and two of system design, with a computer science degree preferred, not required; SDE III asks for about eight years. Any mainstream language is accepted in interviews.

FAQs about the Amazon Software Engineer interview

How long does the Amazon Software Engineer interview process take?

Usually one to three months: about five weeks from referral to decision at SDE II, about six weeks from recruiter contact to a verbal offer for a new graduate, and over six months when the loop came long after the assessment.

What is the hardest round of the Amazon Software Engineer interview?

For most candidates, the Bar Raiser round: an hour of layered follow-ups from someone outside the team with an outsized say. At SDE II and above, rejections concentrate in system design, usually when schemas came before the customer experience.

Can you use AI tools during the interview?

Only in the assessment's repository task, which supplies a restricted assistant. Candidates confirm they will not use unauthorized generative AI in live interviews, and using it can disqualify a candidacy; one candidate who paused mid-problem was asked whether a second screen was in use.

How much does an Amazon Software Engineer make?

Approximate total annual compensation in the United States:

• L4 (SDE I): ~$180K
• L5 (SDE II): ~$275K
• L6 (SDE III): ~$385K

Packages combine base salary, stock that vests over four years on a back-loaded 5%, 15%, 40%, 40% schedule, and a sign-on bonus paid across the first two years to offset the low early vesting.

What happens after a rejection?

Candidates rejected after a full loop reported a one-year wait before reapplying, and feedback requests usually went unanswered. Earlier-stage rejections have carried a shorter wait.

---

Other Tracks at Amazon

• Amazon Frontend Engineer Interview Process
• Amazon Machine Learning Engineer Interview Process
• Amazon Research Scientist Interview Process