Interview guides · Amazon
Amazon Software Engineer Interview Guide 2026
Prepare for Amazon software interviews with level-specific routes, coding and design drills, Leadership Principle stories and clear official-source boundaries.
Interviewing at Amazon
- Practice bank: 500+ questions
- Rounds: 4
- Typical prep: 2–4 weeks
- Interview reports: 111
Interview rounds
| Round | Questions |
|---|---|
| HR Screen | 7 |
| Online Assessment | 80 |
| Technical Screen | 252 |
| Onsite | 161 |
How hard is the Amazon Software Engineer interview?
| Difficulty | Share | Questions |
|---|---|---|
| Easy | 7% | 35 |
| Medium | 74% | 372 |
| Hard | 19% | 93 |
What Amazon actually tests for
| Topic | Share | Questions |
|---|---|---|
| Coding & Algorithms | 49% | 245 |
| Behavioral & Leadership | 26% | 130 |
| System Design | 13% | 63 |
| Software Engineering Fundamentals | 8% | 42 |
| ML System Design | 1% | 7 |
| Machine Learning | 1% | 7 |
| Data Manipulation (SQL/Python) | 1% | 4 |
| Analytics & Experimentation | 0% | 2 |
Amazon software interview preparation should match the level. Keep coding, design and Leadership Principle evidence connected, but do not turn an SDE II preparation page into a universal schedule for entry-level and senior candidates. This guide offers two routes with specific practice outputs and marks the boundary between official process information and editorial drills.
Use the Amazon practice collection to choose additional prompts, then follow the route that matches your confirmed role.
Start with the assessment information for your level
Amazon’s current software-development topics page is a useful general syllabus. It covers core computer-science and software-engineering preparation, while the SDE II page gives a level-specific example of assessments and loop structure. Read the page relevant to your application and confirm anything unclear with your contact. Do not infer a fixed count for every software role from one level’s page. General software interview topics, SDE II preparation.
For coding, clarify constraints, state an invariant, implement a working baseline and test adversarial inputs. For design, identify the user-visible requirement before naming infrastructure. For behavioral work, use real examples and make your own contribution explicit. You need all three habits even when a particular assessment emphasizes one more strongly.
Choose a preparation route before choosing more questions
An early-career applicant and an SDE II applicant need different practice allocations. Both need correct code and concrete examples of ownership. The experienced route adds more attention to architecture, operational trade-offs and the scope of personal decisions. Confirm your level and assessment instructions before applying either schedule.
| Route | First week | Second week | Evidence to keep |
|---|---|---|---|
| Early career | One timed coding session daily; alternating arrays/maps, trees/graphs and boundary testing; three genuine project stories | Mixed coding mocks, one small object-design exercise and repeated behavioral follow-ups | Runnable solutions, complexity explanations, mistake log and story evidence |
| Experienced / SDE II | Alternate coding with API/data modeling, failure recovery and capacity reasoning; inventory six project decisions | Two mixed mocks, a full design defense and follow-ups on rollout, incidents and disagreements | Code/tests, design invariants, operational signals and decision records |
These are editorial two-week routes, not Amazon interview schedules. Extend a session where the artifact is weak instead of collecting another solved-problem count.
Six drills mapped to the signal
- Duplicate request IDs: retain the first occurrence in input order. State the distinction between input length and distinct IDs. Test empty input, repeated IDs and a repeat near the end. This is coding and data-structure practice.
- Shortest unweighted path: use BFS from a source in a graph with disconnected nodes. Return an explicit no-path result. Test a cycle and source equal to target. This is graph traversal and explanation practice.
- A bounded task queue: define submit, cancel, claim and complete operations. Explain the state transitions and who owns a running task. This is object/API design practice; a class diagram alone is insufficient.
- A retrying notification service: name the idempotency key, durable intent, attempt policy and behavior after a worker crash. Trace a send that succeeds but whose acknowledgment is lost. This is experienced design practice.
- A disputed release: use a real example where you opposed a decision with evidence, then describe what you did once the decision was made. This is behavioral practice; do not manufacture conflict for the story.
- An incident you owned: begin with the symptom, explain mitigation before diagnosis, prove the mechanism and identify the recurrence control. This is operational ownership and behavioral practice.
None is presented as a question Amazon promises to ask. Pick a matching question from the bank, attempt it before reading the solution and retain the artifact above. Early-career candidates should spend more repetitions on drills 1–3; experienced candidates should defend drills 3–6 at a level consistent with their actual responsibilities.
What the published process supports
Evidence checked 8 October 2026. Keep stage count separate from interview count: “interview loop” is one process stage that can contain several conversations.
| Evidence | Scope | Preparation implication |
|---|---|---|
| Amazon’s official SDE II preparation page | Describes application, online assessment, interview loop and outcome; its SDE II loop is four 55-minute interviews | Use this only for the named level, then confirm your invitation |
| Amazon’s official software-development topics page | Advises coding, fundamentals and system-design preparation; recommends confirming topics with recruiting | Practise applying fundamentals and explain decisions |
| Broader candidate round lists | Individual experiences can differ by level, location and hiring path; no single report determines your schedule | Treat reported labels as leads to confirm, not universal requirements |
The SDE II page also describes coding, system-design scenarios and a work-style survey in its assessment. It does not make those details the format for every student or specialist role. If your invitation differs, use it to set the mock conditions and ask recruiting about the discrepancy.
At the end of each week, run one coding attempt without looking at a solution, one design/change-of-constraint discussion appropriate to your level and two behavioral follow-ups. Review where your explanation depended on an unstated assumption. A strong next session has a specific repair, such as “trace the retry after a successful send,” rather than a goal to “study distributed systems.”
A notification-design follow-up for experienced candidates
Use this original prompt: a service sends a reminder when a subscription begins, and many begin at the same instant. Clarify whether a late notification is acceptable, whether duplicate sends are worse than missed sends, and whether the provider supports idempotency. Those decisions shape the failure policy.
Store durable notification intent with a stable (subscription_id, notification_type) identity. A dispatcher claims due work under a lease and a generation or another guard against expired ownership. Workers send at a bounded rate and persist the outcome. Retries use exponential backoff with limits; an exhausted attempt enters a reviewable failure state rather than disappearing.
Now trace the difficult case: the provider accepts the send, but the worker crashes before writing completion. With provider-supported idempotency, a retry can use the same key. Without it, the service may not know whether the side effect happened. Explain the uncertainty and product policy instead of claiming that an internal deduplication table proves exactly-once delivery.
Capacity affects the user promise. For a fictional burst of 60,000 reminders and a sustained provider allowance of 1,000 sends per second, the theoretical dispatch floor is sixty seconds before overhead and retries. If the requirement is “all delivered within five seconds,” that capacity does not meet it. Options include a higher allowance, prearranged scheduling support, a changed timing promise or another delivery mechanism; naming more workers does not raise an external limit.
Rehearse a level-appropriate coding explanation
For the duplicate-ID task, retain a set and append an ID only on its first encounter. State that the expected scan cost depends on input length, while the set grows with distinct IDs. If the contract changes to reject conflicting payloads, store the first payload or a suitable canonical identity as well; the original set is no longer sufficient.
For BFS, explain why a node is marked visited when it enters the queue. Waiting until it leaves can enqueue the same node repeatedly through several neighbors. Track predecessors only if the output requires the path rather than a distance. Test a cycle, a disconnected target and source equal to target.
Early-career candidates can finish these contracts before adding a service design. Experienced candidates should still be able to implement them clearly, then defend the architectural consequences of retries, state and capacity. A senior title does not make a vague coding invariant acceptable.
Answering behavioral questions: STAR with your fingerprints on it
Amazon expects structured stories, and the STAR framework (Situation, Task, Action, Result) is the cleanest way to deliver them. The trap is spending too long on Situation and Task and running out of time before the Action and Result - which is where your judgment and impact actually live. Aim for a brief setup, then most of your airtime on what you did and what changed because of it.
Example answer (Ownership), abbreviated:
Situation: Our checkout service started timing out for a subset of users during peak hours. Task: It wasn't formally my area, but no one was tracking it down, so I picked it up. Action: I traced the latency to an N+1 query, added a batched fetch and a short-lived cache, and wrote a load test to confirm the fix before rollout. Result: P99 latency for that path dropped substantially and the timeout reports stopped. I documented the pattern so the team caught two similar issues later.
Note how the Action and Result carry the weight, the contribution is "I" not "we," and the outcome is concrete without inventing a precise statistic. If you don't have a hard number, describe the direction and magnitude honestly ("dropped substantially," "cut the on-call pages roughly in half") rather than fabricating one.
Make the drills harder by changing one contract
After solving the duplicate-ID drill, change the requirement: identical replays are harmless, but conflicting payloads must be rejected. A set of IDs no longer contains enough information. For graph traversal, add a disconnected node and a cycle. For the bounded queue, specify whether full capacity blocks, drops or rejects. Each change tests whether you understood the contract rather than memorized an implementation.
In the retrying-notification design, trace a worker crash after the external send but before the local completion write. A queue’s delivery guarantee does not automatically make the recipient’s side effect exactly once. Explain idempotency support, uncertainty and the retry decision. In a behavioral follow-up, ask what would contradict your explanation that a change caused the improvement.
Check readiness using artifacts
Before a mock, collect a running solution with boundary tests, a design outline with one failure trace and a real story with an honest result. Afterward, record the first contract you misunderstood, test you missed or claim you could not defend. Repeat that part. Avoid converting a practice score into a predicted Amazon hiring outcome.
Does an entry-level candidate need a senior distributed-systems answer?
Use the confirmed assessment scope. Learn to explain simple APIs, state and failures, but spend preparation time at the level expected of the role. Do not omit design entirely if it is on your schedule, and do not assume the SDE II format applies to a new-grad application.
What if I cannot attach a precise number to a Leadership Principle story?
Describe an observable outcome and explain how you know it occurred. Invented metrics weaken trust. Separate a direct measurement from your interpretation of why it changed.
Is the Bar Raiser a separate preparation curriculum?
Prepare the role and your behavioral evidence for the whole loop. The Bar Raiser’s evaluation responsibility does not imply a fixed special question list.
Sources and Further Reading
Editorial revision: 8 October 2026. Current hiring details remain role-specific; unavailable source pages and unverified timings are identified in the text.