Amazon SDE Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Amazon: every round is scored against the 16 Leadership Principles, including the coding ones.

• The interviewer is not only asking "did it work?" They are filling a scorecard that maps your behavior to specific LPs.
• Did you "Dive Deep" when you clarified edge cases? Did you "Deliver Results" by finishing under time? Did you show "Bias for Action" by starting with a working brute force?
• Each interviewer owns 2-3 LPs going into your loop and writes you up against them afterward with direct quotes from the session, not vibes.
• Internalise this and everything below makes sense: you are measured on behavior, not just output, and the behavior is captured in writing you never see.

2Getting the call (the part most guides skip)#

You cannot interview if you do not get shortlisted. Here is how people actually get in, ranked by what works.

Referral beats everything. A referral is 3-4x more likely to get a screen than a cold application, because it lands in the recruiter's queue pre-vetted instead of in a pile of thousands. Here is how to get one with zero contacts:

• Find Amazon SDEs from your college or city on LinkedIn. Same alma mater roughly triples your reply rate because the ask feels personal, not spammy. Sort by your batch years and shared campus, not by title.
• Send a short, specific note: "Hi, I'm targeting SDE-2 on your org. 3 yrs at [X] building [Y]. Would you be open to referring me? I've attached a 1-page resume." Keep it under 4 lines. One ask, one attachment, no life story. The person refers you in 60 seconds through their internal portal, so make it that cheap for them to say yes.
• 8-10 asks usually yields 2-3 referrals. Do not stop at one person. This is a volume game, and most people simply never ask enough.
• A referral does not skip the bar. It skips the queue. You still have to pass the OA like everyone else, and a bad resume still gets filtered.

Resume rules that pass Amazon's bar and the ATS:

• Impact, not duties. Every bullet = Action + Tech + Measurable result. "Cut API latency 40% (820ms to 490ms) by adding Redis caching and query batching." Numbers in every line that can carry one. "Responsible for the payments service" is a dead bullet. "Owned the payments service handling 2M txns/day at 99.95% uptime" is the same fact that actually scores, because it names scale and reliability, the two things Amazon reads for.
• Top third decides. Recruiters scan 6-8 seconds before they decide to keep reading. Put your strongest, most quantified project first. If your best work is in bullet four, assume it was never read.
• Keywords match the JD. If the role says "distributed systems, Java, AWS," those exact words must appear, truthfully. The ATS filters on literal string matches before a human ever sees it, so "built scalable backends" loses to "built distributed systems in Java on AWS." Mirror the req's own nouns.
• One page for under 8 years of experience. No photo, no "references available," no objective statement. Every line you waste on filler is a quantified bullet you did not write.

Where applications come from, ranked:

• Referral (strongest).
• Recruiter inMail (respond within hours. They move fast, and a full day of silence can lose you the slot to the next person in their pipeline).
• Amazon jobs portal (solid. Apply to a specific req ID, not the generic talent pool).
• LinkedIn Easy Apply (weakest. Your resume drowns in thousands of one-click applies here).

3The loop in detail#

Amazon's process is almost always: Online Assessment, then a virtual "loop" of 4 x 55-min interviews. The OA gates the loop. The loop decides the offer.

The OA is more than code.

• The two coding problems are auto-graded on correctness and on hidden test cases for edge conditions. Code that passes the sample input but crashes on an empty array or a single-element input still fails silently, and you never see which case broke you.
• Write defensive code here. Handle the empty, null, and max-size cases before you submit.
• The work-simulation puts you in a day-in-the-life scenario and asks how you would triage a ticket or respond to a teammate. It is quietly scoring your LPs before a human meets you.
• The work-style survey is forced-choice and maps you to the LPs too. Answer as the engineer who ships and owns, not the one who waits for instructions, without lying yourself into a persona you cannot defend later.

The 55-minute slots are real.

• Budget roughly 5 minutes of intro and LP warmup, 40 minutes of actual work, and 10 minutes for your questions.
• Running out of time with no working solution reads as "could not Deliver Results."
• Pace yourself and glance at the clock at the halfway mark.

After the loop, the debrief decides it.

• Every interviewer writes detailed feedback and the panel holds a debrief where they argue the hire out loud, citing their written notes.
• One strong "inclined" can be overruled by the Bar Raiser.
• This is why a single weak behavioral round sinks otherwise strong coders: the written notes outlive the room, and a panelist who was not there reads your transcript cold and forms a verdict from it.

4The coding rounds, patterns, not problems#

Difficulty: LeetCode Medium, with the occasional Medium-Hard.

• You do not need the Hards.
• A fast, clean, well-explained Medium beats a half-finished Hard every time, because the score is on your process, not on having seen the exact problem.

The 8 patterns that cover roughly 80% of Amazon coding rounds:

1. Hash maps and frequency counting: two-sum family, group anagrams, first-unique-character. If you can turn an O(n²) scan into an O(n) lookup with a map, you have solved half of all Amazon problems. The tell is "find a pair/count/duplicate," which almost always means reach for a map.
2. Two pointers and sliding window: longest substring without repeats, container-with-most-water, minimum-window-substring. Know the expand-right, shrink-left template cold so you can write the window-invalid shrink loop without thinking.
3. Trees (BFS/DFS): level-order traversal, lowest common ancestor, path sum, serialize and deserialize. Be fluent in both the recursive and the iterative stack versions, because "do it without recursion" is a common follow-up.
4. Graphs (BFS/DFS, Union-Find): number of islands, course schedule (cycle detection), word ladder. Amazon loves grid and graph problems and often frames them as warehouse routing or package delivery, so get comfortable treating a 2D grid as a graph where each cell is a node and its four neighbors are edges.
5. Heaps and top-K: K closest points to origin, merge K sorted lists, top-K frequent elements. The pattern is a size-K heap for a streaming-selection problem. The moment you see "top K" or "K closest," reach for the heap and state the O(n log k) up front.
6. Recursion and backtracking: subsets, permutations, combination sum. Have the choose-explore-unchoose template memorised so you are not reinventing the recursion skeleton live while the clock runs.
7. Intervals: merge intervals, meeting rooms (can you attend all, and how many rooms). Sort by start time first. That one line unlocks most of them, and forgetting it is why people flail on these.
8. Dynamic programming (lighter): climbing stairs, coin change, house robber. Amazon rarely goes into hard DP, so nail the 1D and simple 2D cases, be able to explain the recurrence, and move on rather than grinding multi-dimensional DP.

How to practice: roughly 120-150 Mediums by pattern, not randomly.

• Do every "sliding window" problem back to back until the template is reflex, then move to the next pattern.
• Random practice builds a thin layer across everything and mastery of nothing. Pattern blocks build the pattern-match recognition you actually need at minute two of the round, when you have to name the approach before you have fully read the problem.
• NeetCode 150 is a good free ordering that already groups by pattern, so you are not deciding what to solve next.

How to win the round, this is what separates offers from rejects:

• Talk the whole time. Silent problem-solving reads as "cannot communicate," which is a scored LP failure on top of the coding one. Narrate the plan before you type: "I'll start with a brute force at O(n²) so we have something correct, then optimise with a hash map down to O(n)." The interviewer is transcribing your reasoning, so give them something to write down.
• Clarify before you write a line. Ask about input size, duplicates, empty input, negatives, and whether the array is sorted. This is literally "Dive Deep" on the scorecard, and half the time the clarification reveals the intended approach, because a sorted-input answer unlocks two pointers and an unsorted one does not.
• State complexity before and after. Say your brute-force big-O, then say your optimised big-O. Leaving it unsaid makes the interviewer wonder if you even know, and "did not state complexity" is a note they will actually write.
• Test your own code out loud with a concrete edge case: empty input, a single element, a duplicate. Walk the real values through your loop. Catching your own bug before the interviewer does is "Insist on the Highest Standards" and is one of the strongest positive signals in the room.
• Write clean code like it is a code review, because it is. Real variable names, small functions, no single-letter soup past loop counters. They are reading it the way they would read your pull request on the job, and sloppiness here is a direct "would not want this in our codebase" note that no clever algorithm undoes.

5System design, the framework that scores#

Which design round you get depends on the level:

• For SDE-2 this is a full high-level design round.
• For SDE-1 it is usually low-level design or OOP, so expect "design a parking lot" class modeling rather than "design Twitter" scaling.

Use this exact 6-step framework every time, out loud, in order:

1. Clarify requirements, both functional (what it must do) and non-functional (scale, latency targets, consistency vs availability). Pin numbers down: "Are we at 1M users or 100M?" The answer changes every decision after it, so refusing to guess here is the senior move.
2. Estimate users, QPS, and storage. Rough is fine. Showing the method matters more than the exact figure: "10M daily users, 10 requests each, so 100M/day, call it roughly 1,200 QPS average and maybe 5x at peak." Say the peak multiplier out loud, because peak is what the system has to survive.
3. API design, the actual endpoints with their inputs and outputs. This grounds the abstract design in something concrete and gives the interviewer a contract to poke at.
4. Data model, and say SQL vs NoSQL and why. The "why" is the whole point. Naming a database without a reason scores nothing. Tie the choice to the access pattern you just defined in the API.
5. High-level architecture: load balancer, then services, then cache, then database, then queue. Draw it. A diagram the interviewer can point at keeps the conversation anchored and stops you from hand-waving.
6. Scale and bottlenecks: sharding, replication, caching strategy, CDN, back-pressure, and what breaks first when traffic triples. Finding your own bottleneck before they ask is the senior signal that separates an L5 answer from an L4 one.

Classics they ask: URL shortener, distributed rate limiter, order-tracking service, notification system, top-K trending items, a parking lot (LLD), an elevator (LLD).

• Amazon leans toward designs that smell like their own business: order flows, inventory, delivery tracking.
• So if a prompt is open-ended, frame it in that world and it will land well, because the interviewer lives in that world all day.

What scores: trade-offs out loud.

• "I'd use SQL for the order table because I need transactions and strong consistency on payments, and a NoSQL store for the event log because it is write-heavy, append-only, and I can tolerate eventual consistency there." Saying the trade-off, and the reason behind it, is the entire exercise.
• Amazon explicitly evaluates designs on practicality, reliability, scalability, and optimization, so a design that is perfect on paper but impossible to build this quarter scores worse than a pragmatic one you can defend and ship.
• There is rarely a single right answer. There is only whether you can justify the one you chose and name what it costs you, which is the question the follow-ups are circling.

6Behavioral and the 16 Leadership Principles (the real differentiator)#

This is where most qualified engineers get rejected.

• They code fine, then give vague behavioral answers and the Bar Raiser writes "not inclined."
• At Amazon the behavioral round carries as much weight as a coding round, not less.
• Do not treat it as a warmup or as the easy slot you can wing. It is the one people fail.

Write 12-16 STAR stories (Situation, Task, Action, Result) with numbers in every Result, mapped across the LPs.

• One strong, detailed story can cover 2-3 LPs if you emphasise different parts of it, so you do not need 16 separate incidents.
• You need 12-16 stories deep enough to survive four follow-ups each without inventing details on the spot.

The 16 LPs: Customer Obsession • Ownership • Invent and Simplify • Are Right, A Lot • Learn and Be Curious • Hire and Develop the Best • Insist on the Highest Standards • Think Big • Bias for Action • Frugality • Earn Trust • Dive Deep • Have Backbone, Disagree and Commit • Deliver Results • Strive to be Earth's Best Employer • Success and Scale Bring Broad Responsibility.

The ones that come up most for engineers: Ownership, Dive Deep, Bias for Action, Deliver Results, Customer Obsession, and Have Backbone.

• Make sure you have at least two airtight stories for each of those six.
• They are the spine of nearly every loop, and the interviewer owning that LP will keep digging until they are satisfied or they run out of time.

STAR example, "Ownership" (study the shape, then write your own):

S: Our checkout service was throwing 5xx errors for roughly 3% of users during peak traffic, and no one owned the root cause because it sat between two teams. T: I took it on even though it was not my service, because the revenue bleed was real and nobody else was going to. A: I traced it to connection-pool exhaustion under load, added proper pooling and a circuit breaker so failing calls degraded gracefully instead of cascading, and wrote a runbook so the on-call engineer could handle a recurrence without me. R: 5xx errors dropped from 3% to 0.1%, and we recovered roughly ₹4L/month of previously abandoned carts. I then presented the fix to two other teams who had the same connection-pool pattern.

Why that story works:

• A specific metric at both ends (3% to 0.1%, ₹4L/month).
• A clear "I" taking something that was not mine.
• A result that scaled beyond the original problem. That last part quietly signals "Think Big" and "Earn Trust" on top of Ownership, which is how one story covers three LPs and why depth beats breadth.

Rules for behavioral:

• Say "I," not "we." They are scoring your actions, and "we" is where candidates hide the fact that they did not actually do the work. When you must mention the team, make your specific contribution unmissable: "the team shipped it, but I was the one who designed the retry logic and caught the race condition in review."
• Every story needs a metric in the Result. No number means no result they can score. "It went much faster" loses to "P99 dropped from 1.2s to 300ms." If you genuinely do not have a hard number, give a proxy: tickets closed, hours saved per week, percent of traffic covered.
• Expect 3-4 follow-ups per story: "why that approach and not the alternative?", "what would you do differently?", "what did the data actually say?", "how did you handle the pushback?" This is the Bar Raiser digging for whether the story is real and whether you understood it deeply, not just executed someone else's plan. Have that depth ready. Shallow stories collapse on the second "why," and that collapse is the rejection.
• Prepare one real Have Backbone / Disagree and Commit story where you pushed back on a decision, lost or won, and then committed fully to the outcome either way. Candidates dodge this one or tell a story where they were simply right, and both read as having no spine. The disagree-then-commit arc is the whole point.
• 2026 note: candidates consistently report at least one question on judicious, honest use of AI tools in your work, framed around judgment and integrity. Have a genuine answer about where AI helped, where you verified its output, and where you chose not to rely on it. The wrong answer is pretending you never use it. The right one shows judgment, because the LP being tested is whether you can be trusted with a powerful tool without cutting corners.

7Your prep plan#

Pick the plan that matches your runway. Each one front-loads coding because that is where you cannot fake fluency, and back-loads behavioral because stories can be sharpened quickly once they are written down.

4-week plan (recommended):

• Week 1: Coding patterns 1-4 (hash maps, two pointers, trees, graphs), about 40 Mediums, and narrate every single one out loud as if an interviewer were watching. Silent practice builds a skill you cannot use in the room, because the room scores the narration.
• Week 2: Coding patterns 5-8 (heaps, backtracking, intervals, DP), about 40 more, plus a revisit of whichever pattern from Week 1 still feels slow. Keep a short list of the three problems that beat you and redo them cold at week's end.
• Week 3: System design. Learn the 6-step framework and run 5-6 full designs end to end, out loud, with a timer set to 45 minutes. Record yourself once. The gaps, the hand-waving, the steps you skipped, are obvious on playback and invisible while you talk.
• Week 4: Write and rehearse 12-16 STAR stories, then do 2 full mock loops with someone who will push back on your answers with real follow-ups, not nod along. A friendly mock that never challenges you is worse than none.

2-week plan:

• Days 1-7: coding by pattern, 2-3 focused sessions a day, always narrated out loud.
• Days 8-10: system design framework plus 3-4 practice designs out loud with a timer.
• Days 11-13: write and rehearse STAR stories, at least one pass with a mock partner who challenges the "why."
• Day 14: one full mock loop to simulate the fatigue of four back-to-back rounds, because stamina fails people in the last slot.

2-day crash:

• Day 1 AM: the top 8-10 Mediums by pattern, one from each of the 8 patterns, to confirm you can name the approach fast. PM: draft 6-8 STAR stories.
• Day 2 AM: the one design framework plus 1 practice design end to end. PM: rehearse every story out loud until the follow-ups stop surprising you and the metrics come out without hunting.

8Why people get rejected at Amazon (learn from these)#

1. Silent coding. Solved it but did not communicate the thinking. This is an auto-fail signal because "cannot explain my work" is a hard no for a company that runs on written docs and peer code review all day.
2. "We" behavioral answers. No personal ownership, no numbers, so the interviewer cannot tell what you actually did versus what you watched happen.
3. No trade-offs in design. Listed components but never justified a single choice. A design with no "why" is a diagram, not an answer, and the follow-ups will expose it in a minute.
4. Shallow under follow-up. The Bar Raiser asks "why" three times and you run out of depth by the second, which signals the story was not really yours or you did not understand it.
5. Ignoring edge cases. Did not clarify the input and crashed on empty or null. This fails both the coding bar and "Dive Deep" in one move.
6. Not testing your own code. The interviewer finds the bug instead of you, which reads as low standards even if the logic was otherwise fine, because on the job you ship the bug too.

Fix all six and you are ahead of most candidates who have the exact same coding ability. The loop rewards the engineer who communicates and owns, not just the one who solves, and that is a gap you can close in a week of deliberate practice.

9The offer, comp and negotiation#

• Amazon's base salary is capped, especially in the US where cash base tops out around the mid-100s regardless of level. The rest of your comp comes via a sign-on bonus paid across Year 1 and Year 2, and RSUs that vest on a 5/15/40/40 schedule over 4 years. That back-loaded vesting is deliberate: the sign-on bonus front-loads your cash in the early years to smooth over the thin 5% and 15% RSU vests, which is exactly why Years 1 and 2 feel fine and Year 3 can dip hard if the stock has not grown enough to cover the jump to 40%. Model all four years before you accept, not just Year 1, and ask the recruiter for the per-year breakdown in writing.
• Always negotiate. The first offer has room built into it, and recruiters expect a counter. Not countering leaves money on the table every time. Use a competing offer if you have one: "I'm genuinely excited about Amazon. I have an offer at [X] total. Can you improve the RSU grant or sign-on to close the gap?" Be specific about the gap and the exact lever you want moved.
• If you have no competing offer, push on the sign-on bonus. It is the easiest lever for a recruiter to move because it does not touch the base band or the leveling guidelines, so it needs less approval, and a few lakh or a few thousand dollars there is often a quick yes.
• Get the level right (L4 vs L5). This matters far more long-term than ₹2-3L of signing money today. The level sets your base band, your RSU band, and how long until your next promotion. Landing at L5 instead of L4 can be worth tens of lakhs over a few years, so if your experience supports it, make the case before you accept, not after, because re-leveling post-offer almost never happens.

10FAQ#

Ready to prep against your exact target role and timeline? Build your personalized, dated plan.