← All posts
general

Amazon Software Engineer Interview: SDE I to Principal

The Amazon software engineer interview is one of the most standardised loops in big tech, and that is exactly why it catches people. The stages are the same for a new graduate and a Principal: an online assessment or a phone screen, four to six interviews, a debrief you never see. What moves is the bar. The same coding question, the same "tell me about a time" question and the same system design prompt are graded against a different standard at each level, and most guides describe the SDE II version and leave everyone else guessing.

This guide covers the stages as they apply to software development engineers (SDEs), then what changes at SDE I, SDE II, Senior SDE and Principal. Amazon does not publish its interview format; where candidates and former interviewers consistently report something, the guide says so, and where teams and years differ, it says that too. For the process across all roles, read the Amazon interview process guide; this one stays with engineers.

The stages for an SDE

For an SDE role the sequence candidates report is:

  1. Online assessment. Standard for new graduate and intern roles, common for experienced SDE roles. Two timed coding problems plus a work-style section built around the leadership principles. The Amazon online assessment guide covers the format and a plan for it.
  2. Phone screen. One interviewer, 45 to 60 minutes, one coding problem in a shared editor and one or two behavioural questions. Candidates who come through a new graduate pipeline sometimes skip this stage and go from the assessment straight to the loop.
  3. The loop. Four to six interviews, each 45 to 60 minutes, each with a different interviewer. For an SDE that typically means two coding rounds, one system design round from SDE II up, a round with the hiring manager that is mostly about the leadership principles, and the Bar Raiser. Every round contains behavioural questions; every interviewer owns two or three principles.
  4. The Bar Raiser. One of the loop interviewers, from outside the hiring team, trained for the role after running many interviews, with the standing to block a hire. Their round looks like any other; their follow-ups go deeper. The Bar Raiser guide covers it.
  5. Debrief. The interviewers submit written feedback, then meet, usually within days, and decide: hire at level, hire at a lower level, or no hire. The debrief guide explains how that meeting runs and what makes feedback read well.

Two facts are worth knowing before you prepare. Interviewers rarely ask about Amazon's internal tools or services; the interview tests how you solve problems and how you have worked, not what you know about Amazon's stack. And interviewers share notes, so a story told in the hiring manager round can be picked up by the Bar Raiser from a different angle.

Coding rounds

An SDE loop usually has two coding rounds, and candidates report that they differ. Interviewers describe different flavours: one focused on data structures and algorithms, one on writing logical, maintainable code (object modelling, clean interfaces, a requirement that changes halfway through), and sometimes one framed as open-ended problem solving, where the question starts vague and you have to scope it before you code. Which flavours you get varies by team and level.

What they test:

  • Working code. Not pseudocode. The interviewer expects a solution that would run, with the obvious edge cases handled (empty input, a single element, duplicates, large inputs). At Amazon, this is where Insist on the Highest Standards is graded in practice.
  • Patterns, not memorised problems. Hash maps and counting, two pointers and sliding windows, sorting and intervals, BFS and DFS on trees and graphs, heaps for top-k, and simple dynamic programming cover most of what candidates report. The question is rarely a famous one verbatim; it is a familiar pattern with a warehouse, a delivery route or a product catalogue around it.
  • Complexity, stated unprompted. Say the time and space complexity of your approach before you are asked, and say what you would trade to improve it.
  • Talking while coding. Narrate the decision, not the syntax. "I am using a map here so lookups are constant" is useful; reading your own code aloud is not.

Behavioural questions sit inside the coding rounds, not just the hiring manager round. A common shape is 15 to 20 minutes of leadership principle questions first, then the coding problem. Candidates who treat the opening questions as warm-up lose points before they have written a line.

How to practise: timed, out loud, in a plain editor without autocomplete, with a listener who asks "why" at least twice. Our mock interviews guide covers how to run that with a friend or a coach. The free practice interview on techinterview.coach has a coding talk-through round for the narration part (free, sign in with LinkedIn).

System design round

From SDE II up, one round is a system design problem: 45 to 60 minutes, one interviewer, a whiteboard or a shared drawing tool. The prompt is usually a service Amazon would plausibly build (a notification system, a rate limiter, an inventory service, a metrics pipeline), and the interviewer is less interested in the final diagram than in how you got there.

A design that passes at Amazon, as candidates describe it, covers in rough order:

  1. Requirements. Functional and non-functional, with numbers you asked for or estimated: users, requests per second, data size, latency targets. Customer Obsession shows up here as "who is the customer and what do they need from this".
  2. API and data model. The handful of operations the system exposes and the shape of the data behind them.
  3. High-level design. Services, storage, queues, caches, and the reason each box exists.
  4. Scale. Where it breaks first, and what you change: partitioning, replication, caching, asynchronous work.
  5. Trade-offs. Consistency against availability, cost against latency, simplicity against flexibility, said out loud with your pick and your reason.
  6. Operations. Monitoring, alarms, failure modes, how a deploy goes wrong and how you would know. Amazon interviewers consistently probe this part harder than most companies, and it is where Dive Deep and Ownership are graded in a technical round.

Naming AWS services is fine and not required; a queue is a queue. What costs candidates the round is a design they cannot defend when the interviewer pushes on one component. The system design interview guide covers the method, and the system design questions by level shows how the same prompt is graded differently at mid-level, senior and above.

Leadership principles in an SDE loop

Amazon has 16 leadership principles, and every interviewer in the loop is assigned two or three to assess. Job descriptions for SDE roles often name a handful of them. In practice, candidates report that the ones that come up most for engineers are Customer Obsession, Ownership, Dive Deep, Deliver Results, Learn and Be Curious, Insist on the Highest Standards, Bias for Action, Have Backbone; Disagree and Commit, Earn Trust, Invent and Simplify, and Are Right, A Lot. Which ones your loop emphasises varies by team.

A coding interviewer asks a principle question the same way a hiring manager does: "Tell me about a time when...", followed by two or three follow-ups that test whether the story is yours and whether the detail holds. Questions candidates report in SDE loops include:

  • Tell me about a time you took a risk, made a mistake or failed. How did you respond?
  • Tell me about a conflict with a colleague and how it was resolved.
  • Tell me about a time you took the lead on a difficult project.
  • Tell me about a time you received hard feedback from your manager, and what you did with it.
  • Tell me about a time you had to make a decision with incomplete information.
  • Tell me about a time you went deeper into a problem than anyone asked you to.

The answer format is STAR (Situation, Task, Action, Result) with your personal role explicit and a measured result. Build a bank of eight to ten stories covering success, failure and team situations, and tag each with the two or three principles it serves; most stories serve more than one. Do not make excuses for mistakes, do not overclaim, and keep the answer to about two minutes before the follow-ups. The STAR method guide, the story bank guide and the 60 behavioural questions by principle cover the groundwork.

SDE I and new grad

SDE I (Amazon's L4) is the entry level, and the process for new graduates differs in two ways. The online assessment carries more weight, because for many candidates it is the only technical screen before the loop; and the loop is often shorter, with candidates reporting three or four interviews and sometimes no separate phone screen.

The coding bar is about fundamentals done cleanly under time: correct, readable, edge cases covered, complexity known. Interviewers do not expect design experience, and a full system design round is unusual at this level, though a short "how would you structure this" discussion inside a coding round is not.

The leadership principle questions are the same, with lighter expectations of scope. Ownership for someone with an internship and a final-year project means: you saw something nobody had asked you to fix, you fixed it, you told people. Deliver Results means a deadline you hit, or missed and recovered from, with what you learned. Interviewers at this level are checking that you can reflect on your own work honestly, not that you have run a team. Candidates who inflate a university project into an organisational turnaround read worse than those who describe it plainly.

SDE II

SDE II (L5) is the default loop that most guides describe: a phone screen, then four or five interviews including two coding rounds, a system design round, a hiring manager round and the Bar Raiser.

The system design round appears here for the first time, and candidates consistently report that it is what separates a hire from a down-level to SDE I. The expectation is a working design for a well-scoped service with sensible trade-offs, not a multi-region platform.

Stories at SDE II should show you owning a feature or a component end to end: you understood the customer need, you made technical decisions and lived with them, you dealt with an ambiguous requirement or a disagreement, and you shipped something measurable. Interviewers listen for the first person singular. "We decided" is a team story; "I proposed X because Y, the team pushed back on Z, we went with X and here is what happened" is yours.

Senior SDE

Senior SDE (L6) is where the shape of the loop stays the same and the grading changes most. Candidates report five or six interviews, with system design given more time and more depth, and behavioural questions that circle influence rather than delivery.

What interviewers look for, as candidates and former interviewers describe it:

  • System design depth. You should be able to go two levels down on any component you draw: how the partition key is chosen, what happens when a replica lags, how the backlog is drained after an outage. Operational scars are evidence.
  • Influence beyond the team. Decisions that crossed team boundaries, a design review you ran for another team, a standard you set that others adopted.
  • Ambiguity resolved, not waited out. A story where the requirements were unclear and you did the work to make them clear, including the conversations with the people who owned the answer.
  • Mentoring and raising the bar. How you have made other engineers better, with a specific person and a specific change.
  • Have Backbone at scale. Disagreeing with a manager or a senior peer, with data, and either changing the decision or committing fully once it was made. The Have Backbone guide covers the shape.

A frequent failure at this level is bringing SDE II stories with bigger numbers. Scope is the signal, and the Bar Raiser is calibrated to notice when the evidence supports L5, which is how a strong candidate ends up with a down-level offer. Ask the recruiter which level you are being interviewed for before the loop, and prepare stories for that level.

Principal engineer

The Principal (L7) interview is a different shape, and this is the section to hedge hardest: Amazon does not describe the process, Principal loops are rarer, and candidates' accounts vary more than at any other level.

What they report in common: more interviews than a Senior loop, sometimes spread over more than one day; a technical presentation or deep walkthrough of a past piece of work, in some loops as a written document reviewed beforehand, in others as a talk with questions; system design at the level of a platform or an organisation's architecture rather than one service; and behavioural questions about setting technical direction, influencing across organisations, and making bets with incomplete data.

Themes to expect at this level:

  • Technical strategy. Why your organisation built what it built, what you would have done differently, how you decided what not to build.
  • Cross-organisation influence. Changing the direction of teams you did not manage, with how you handled the people who disagreed.
  • Customer Obsession at the business level. A technical decision you made because of what it meant for customers or the business, with the numbers.
  • Developing other senior engineers. How the Senior engineers around you grew, specifically.
  • Written communication. Amazon's culture runs on written narratives, and candidates report that the written parts of a Principal process are read closely.

The staff engineer interview guide covers the equivalent level at other companies, and most of its advice on scope and influence applies.

Timeline and the wait

Candidates report three weeks to three months from application to offer, with the gap between loop and decision the most variable part: usually two days to two weeks. Phone screen to loop is commonly one to four weeks, longer when a panel has to be assembled across time zones. Principal processes run longer. The Amazon interview process guide has the stage-by-stage timing. Keep practising while you wait, and tell the recruiter early if you have a competing offer with a date.

Common mistakes by level

  • SDE I. Treating the online assessment as a formality; over-engineering a coding answer instead of getting a clean one working; inflating a small project rather than describing it honestly.
  • SDE II. Preparing only for coding and arriving at the system design round without a method; telling team stories in the first person plural; not asking which level the loop is for.
  • Senior SDE. SDE II stories with bigger numbers; a design you cannot defend two levels down; no mentoring or cross-team story in the bank; disagreeing without data, or agreeing with everything.
  • Principal. Describing outcomes without the strategy behind them; a presentation that lists what was built instead of why; no story about a bet that went wrong.
  • Every level. Treating the behavioural questions in a coding round as warm-up; one great story told to every interviewer; a vague result ("it went well") where a number belonged; going quiet during the wait instead of asking the recruiter for a status.

Where coaching fits

If the gap is technical, the fix is practice: timed problems, written designs, and a method for the 45 minutes. If the gap is that you cannot tell whether your stories and your designs pass at your level, that is what a mock with someone who has sat in Amazon debriefs is for. Six of the 23 coaches on techinterview.coach (as of October 2026) have Amazon on their history; you can browse them by company, read how they run a session, and book a single mock before deciding on more. For free, the practice interview runs a behavioural round prefilled on the Amazon leadership principles and gives you a written recap of what worked and what to drill (sign in with LinkedIn). The Amazon interview coaching guide explains what a coach does and what to ask before booking.

Related guides