The gap between Amazon’s engineering levels isn’t years, it’s blast radius

Search Console shows people typing “amazon sde 2 interview experience” and “amazon interview questions sde2” into Google and mostly not clicking anything. Across a 45-day window on our own site, “amazon interview questions sde2” pulled 19 impressions at an average position of 41.8 across seven monitor checks, and “amazon sde 2” pulled 3 impressions sitting at position 42. Nobody’s reading page four of Google results, which means most of what’s already ranking for this query isn’t actually answering it. What people want to know is simple and rarely stated plainly: what changes between SDE 1, SDE 2, and SDE 3 that isn’t just a number on a badge.

The honest answer is scope, and specifically who has to clean up when something breaks.

What Amazon SDE 2 actually owns that SDE 1 doesn’t

An SDE 1 at Amazon typically owns a well-defined piece of a system: a service, a feature, a component with edges someone else already drew. The work is real engineering, but the blast radius of a mistake is usually contained to a code review catching it, or a rollback fixing it within the sprint. Someone more senior already decided the shape of the thing you’re building.

Amazon SDE 2 is where that changes. An SDE 2 is expected to own an entire service or a meaningful slice of a larger system end to end, including the parts nobody explicitly assigned: the on-call rotation, the postmortem when it pages at 3am, the decision about whether a fix is a patch or a rearchitecture. The technical bar goes up, but the bigger shift is ownership. Nobody’s checking your design before you ship it anymore; you’re the one other people check with.

That’s a real jump, and it’s why so many engineers report the SDE 1 to SDE 2 promotion as harder to land than SDE 2 to SDE 3 later, even though the title gap looks smaller on paper. Part of the reason is timing. Most engineers hit the SDE 1 to SDE 2 wall two to three years in, before they’ve had many chances to actually own an incident end to end, so the promotion loop is asking for evidence they genuinely haven’t accumulated yet. By the time someone is up for SDE 3, they’ve usually lived through enough on-call weeks that the ownership stories exist; the harder part at that stage is picking which three to tell.

SDE 3: the level where you stop owning code and start owning outcomes

An SDE 3 at Amazon is expected to design systems that span multiple services and, often, multiple teams, and to be accountable for outcomes that no single service metric captures cleanly. The work shifts from “can I build this correctly” to “is this the right thing to build, and will it still be the right thing in two years.” A bad SDE 3 decision doesn’t get caught in a code review. It gets caught eighteen months later when three teams have built on top of a design that didn’t scale.

That’s the blast radius difference in one sentence: an SDE 1’s mistake costs a sprint, an SDE 2’s mistake costs a service, and an SDE 3’s mistake costs a program, sometimes one that outlives the person who made the original call by a promotion cycle or two. The compensation reflects that risk profile as much as it reflects raw skill. Median total compensation across all US software engineering roles was $135,980 as of May 2025 according to the Bureau of Labor Statistics, though that figure covers every level and every company, not Amazon specifically, so treat it as a floor for the conversation rather than a number to compare directly against any single level’s package.

I don’t have a verified, Amazon-specific comp figure by level to cite here, and I’d rather say that plainly than repeat a number I pulled from a forum post. If you want a general sense of how title and comp diverge across companies at the same nominal seniority, the 2025 Stack Overflow Developer Survey found engineering managers reporting a $200,000 US median against $52,308 in India for the same title, which is a useful reminder that titles alone tell you almost nothing about pay without a location attached.

The Leadership Principles get graded differently at each level

Amazon’s fourteen Leadership Principles don’t change wording between levels, but the bar for what counts as evidence does. An SDE 1 answering “Ownership” might describe fixing a flaky test suite nobody else wanted to touch. An SDE 2 answering the same principle is expected to describe a decision they made that traded off short-term speed against long-term maintainability, and defend why. An SDE 3 is expected to describe influencing a decision outside their own reporting line, because “Ownership” at that level includes things you don’t have direct authority over.

We’ve written the full breakdown of how these principles get interpreted question by question in Amazon Leadership Principles interview, and it’s worth pairing that with the mechanics of the earlier screening stage in the Amazon online assessment guide, since a strong OA doesn’t guarantee the bar drops in the behavioral rounds later. The two stages test almost entirely different things, and treating the OA as the hard part while winging the behavioral rounds is a mistake that shows up in rejection feedback more often than it should.

What the interview loop adds at each level, beyond harder coding

Coding difficulty does rise a little from SDE 1 to SDE 3, but not nearly as much as candidates expect; the bigger change is what gets added to the loop. SDE 2 loops typically add a dedicated system design round that SDE 1 loops skip entirely or touch lightly. SDE 3 loops add a second design round, sometimes framed around an ambiguous, underspecified problem on purpose, specifically to see whether the candidate asks the right clarifying questions before designing anything. That deliberate ambiguity trips up strong coders more than weak ones, oddly, because a candidate who’s used to a clean problem statement will often start designing before asking what “the system” is even supposed to do, who its users are, or what scale it needs to handle on day one versus year three.

Bar raisers, the specially trained interviewers Amazon embeds in every loop regardless of level, are scored slightly differently too. At SDE 1, a bar raiser is mostly checking for red flags: can this person actually code, will they get along with a team. At SDE 3, the bar raiser is checking whether this person will raise the technical bar of the org around them, which is a much harder thing to assess in 45 minutes and a big part of why SDE 3 loops run longer and involve more interviewers per candidate. Five or six interviewers is normal for a senior loop. A single bar raiser can veto a hire regardless of what the rest of the panel scored, which is a structural check most other companies don’t replicate exactly, even the ones that borrow the Leadership Principles format wholesale.

Down-levelling: how it actually happens and what it means

Down-levelling is when a candidate interviews for one level, usually SDE 2 or SDE 3, and receives an offer at the level below. It isn’t a rejection dressed up nicely; it’s Amazon’s loop concluding that the candidate cleared the coding and behavioral bar but didn’t demonstrate enough evidence of the ownership scope required at the target level. This tends to happen most at the SDE 2 to SDE 1 boundary, where a candidate might code cleanly under pressure but give thin, hypothetical-sounding answers to ownership and design questions because they genuinely haven’t had the chance yet to own something at that scale.

Whether to accept it is a separate call

Whether to accept a down-levelled offer is its own decision, separate from whether the loop judged you fairly. Some candidates take the SDE 1 offer, prove the scope claim on the job within a year, and get promoted faster than they would have climbed externally at the higher title elsewhere. Others decline and reinterview later once they’ve built the missing ownership evidence somewhere else first.

A down-level isn’t permanent and it isn’t rare. What surprises people is that it can happen even with a technically flawless coding round, because the coding bar and the scope bar are graded as separate signals, not averaged together. If every technical answer is strong but every ownership story is thin, the loop can still conclude you’re not yet operating at the level you applied for. Recruiters sometimes flag the possibility before the loop even starts, especially for external candidates jumping from a smaller company where the team size and blast radius were both much smaller than Amazon’s default. Internal transfers get down-levelled far less often, mostly because their manager has already vetted the scope claim before the loop begins. That asymmetry is worth knowing if you’re comparing an internal move against an external offer at the same nominal title; they are not the same bet.

So which level should you actually prep for

If you can’t yet describe a time you owned a service end to end, including the on-call pain, prep as if you’re SDE 1 and let the loop surprise you upward rather than betting on a level you can’t yet back with real stories. If you’ve got two or three ownership stories with actual blast-radius consequences, you’re probably SDE 2 material and the design round is where you’ll separate from the pack, not the coding round. There’s no shame in interviewing for a level below where your resume says you should be, either. A candidate who nails an SDE 1 loop and gets fast-tracked to SDE 2 within a year is in a stronger position than one who scrapes into SDE 2 on a generous interviewer and then spends eighteen months visibly underwater, because the second path burns manager trust that’s expensive to rebuild.

SDE 3 prep is a different exercise entirely: less time on algorithms, more time rehearsing how you’d explain a cross-team design tradeoff to someone who wasn’t in the room when you made it. That’s the skill the loop is actually testing at that level, whether or not the job description says so directly. If you’re switching between prepping for Amazon SDE 2 one week and a different company’s senior loop the next, don’t assume the ownership bar transfers cleanly. Some companies grade scope more loosely at the same title, others more strictly, and treating every senior-title interview as identical is a common way candidates walk in underprepared for the specific thing Amazon’s loop checks for.

The one habit that actually moves the needle

One thing I’ll say with less hedging: whatever level you’re prepping for, rehearsing an ownership story out loud, to another person, catches gaps that rehearsing it silently in your head never does. It’s a small habit. It’s also the difference between a story that sounds complete in your own head and one that survives a follow-up question from a bar raiser who’s heard five hundred versions of it before.

I’m genuinely unsure how much of the down-level pattern generalizes beyond Amazon specifically; other FAANG-adjacent companies grade scope differently, and I haven’t run the same comparison across all of them. If you’re prepping across multiple companies at once rather than just Amazon, that inconsistency between how different loops grade the same seniority is worth building into your prep plan rather than assuming one script works everywhere.