Amazon Senior Software Engineer Interview: What the Bar Actually Looks Like
- The core SDE3 shift: SDE2 asks whether you can solve hard problems; SDE3 asks whether you own the problem space.
- Reaching optimal isn't enough at SDE3: you need time left to discuss alternatives, tradeoffs, and edge cases without being prompted.
- System design is evaluated on tradeoffs, not correctness: know the failure modes of every component you choose and how the design evolves under different business assumptions.
- Leadership Principle stories need cross-team scope: if an SDE1 could have told the same story, find a better one.
- The bar raiser holds formal veto power: they will spend up to 20 minutes on a single LP story peeling back every claim.
- Structured prep over 6-8 weeks: DSA weeks 1-2, system design weeks 3-4, LP story audit weeks 5-6, full mock loops weeks 7-8.
If you've already passed an Amazon loop at the mid-level, you know the format. Phone screen, a few coding rounds, a behavioral, a bar raiser. The structure at SDE3 looks almost identical. The bar is not.
This is the part that bites people. They prep for SDE3 the way they prepped for SDE2, just harder. More LeetCode, more LP stories, more system design diagrams with arrows pointing at boxes labeled "Cache." They walk into the loop technically solid. They get the feedback: "Not quite at the senior bar." Which tells them almost nothing.
This guide covers what actually shifts when you're interviewing for a senior role at Amazon (L6/SDE3, or L5 with senior scope in some orgs): what changes, what gets added, and how to prep differently. For the full picture from SDE1 onward, the Amazon software engineer interview guide covers the whole loop.
The Loop, Round by Round
Amazon's senior loop is typically five to six rounds, run as a virtual onsite over one day or split across two half-days. One round is the bar raiser. One or two are coding. One is system design. The rest blend behavioral and technical in the same conversation.
| Round | Format | What It Tests |
|---|---|---|
| Recruiter / Screening | 30 min phone call | Leveling fit, LP surface |
| Technical Phone Screen | 45-60 min, CoderPad | DSA, communication, LP |
| Coding Round 1 | 45 min | Algorithms, problem-solving |
| Coding Round 2 | 45 min | Algorithms, edge cases, complexity |
| System Design | 60 min | Architecture, tradeoffs, scale |
| Bar Raiser | 60 min | Holistic bar check across coding + LP |
| Behavioral / Hiring Manager | 45 min | LP depth, scope, team fit |
The bar raiser can appear in any slot. You won't be told which interviewer holds the role.
What Actually Changes at the Senior Level
Most people get this wrong: they treat SDE3 as a harder SDE2. Same game, higher difficulty slider. It's not.
At SDE2, the question is "can you solve hard problems?" At SDE3, the question is "do you own the problem space?"
Amazon's own prep guide for SDE3 puts it plainly: you're expected to design for ambiguity, drive long-term system evolution, and align across teams with no stake in your work. The coding and design questions are still there. They're a substrate. What interviewers are actually extracting is scope and judgment. Can this person see around corners? Do they operate across team boundaries, or do they stop at the edge of their own Jira board?
The shift shows up in three concrete places.
Scope of your examples. LP stories at SDE2 can live within your team's boundary. At SDE3, they need to show influence beyond it. Not necessarily hundreds of engineers, but cross-team alignment, architectural decisions that outlive you, processes you installed rather than just followed.
System design depth. SDE2 asks you to design something scalable and maintainable. SDE3 asks you to design for constraints you can't fully know, explain why you'd build it differently under different business assumptions, and anticipate the org problems your architecture creates. The document you'd write as an SDE3 is 8 to 12 pages aimed at directors, not 3 to 5 pages for your immediate team.
Dive Deep in real-time. Senior interviewers probe. They follow up. They ask for specific numbers, for the alternative you considered and rejected, for the failure mode nobody thought about until production. Vague answers that would slide by at SDE2 get flagged at SDE3.
Coding: Same Format, Shifted Expectations
Two coding rounds, 45 minutes each. Difficulty is LeetCode medium to hard. The format is identical to SDE2. What counts as a complete answer is not.
At SDE3, hitting optimal fast enough to discuss alternatives and edge cases is the expectation, not the bonus.
Common patterns in SDE3 coding rounds:
- Graphs (BFS/DFS, Dijkstra, topological sort)
- Dynamic programming (medium-hard, not trick DP)
- Heaps and priority queues
- Trees with complex traversal or state tracking
- Two pointers and sliding window (often a warm-up in a two-problem round)
One thing candidates miss: Amazon interviewers want you narrating complexity without being asked. If thinking out loud isn't already your default, build that habit before the loop. "This runs in O(n log n) with O(n) space. If memory were the constraint, here's how I'd trade time for O(log n) space." That's engineering judgment, not just problem-solving.
Proactively surfacing edge cases before the interviewer prompts you is an explicit signal. Waiting to be asked is a yellow flag at this level.
No matter how many papers you've published, the first reply is always the same.
System Design: Designing for Ambiguity, Not Correctness
Sixty minutes. Ambiguous requirements. Real scale. Common prompts: design a notification system, a distributed key-value store, a content recommendation pipeline, a rate limiter for a multi-tenant API.
Notice that none of these have a single correct answer. That's intentional. The bar isn't a correct architecture. What interviewers are evaluating is whether you can navigate ambiguity, make explicit tradeoffs, and design a system that could actually run in production across AWS regions.
A strong SDE3 design covers:
- Clarifying functional and non-functional requirements (read/write ratio, latency SLA, regions, failure model)
- A rough capacity estimate that informs your choices, not just box-checking
- Core architecture with explicit tradeoffs ("I'm choosing eventual consistency here because strong consistency at this write throughput would require X, and the use case tolerates brief staleness")
- Where the design breaks (hot partitions, thundering herd on cache miss, cross-region replication lag)
- How it evolves under different product assumptions
What gets candidates dinged: correct architecture with no tradeoff discussion, not knowing the failure modes of the components you chose, treating scale as a later concern.
Amazon runs on AWS and its own internal infrastructure. Know why you'd choose DynamoDB over RDS for a particular access pattern. Distributed systems fundamentals matter: consistent hashing, CAP, the tradeoffs around consensus. You don't need to recite Paxos. You need to know what you're giving up when you pick a particular design.
Leadership Principles: Scope Is the Signal
Every interviewer is assigned two to three Leadership Principles to probe. You won't know which ones. The five that surface in nearly every senior loop: Customer Obsession, Ownership, Dive Deep, Deliver Results, and Earn Trust.
STAR format still works. The problem is that most senior candidates have weak stories: scope too small, the "action" describes what the team did rather than what they specifically did, results are vague or missing numbers entirely.
Bar raisers have a specific tell. They follow up every single answer with "What specifically did you do?" This is designed to break candidates who are inflating team contributions. If the story collapses under that question, the bar raiser has their answer.
What senior LP stories actually look like:
Ownership at SDE3. You noticed something was going wrong before it was your problem. You surfaced the risk with data, aligned stakeholders, and shipped a fix that reduced the risk structurally. Not a one-time heroic fix. A durable improvement that other teams didn't have to replicate.
Dive Deep at SDE3. You didn't just know your system had a problem. You traced it through five layers of abstraction, and you knew the numbers cold. Interviewers test this mid-story. "What was your P99 latency before and after?" If you say you don't remember, the story loses most of its signal.
Invent and Simplify at SDE3. You removed a process that was creating drag across teams, or proposed an architectural simplification that let three teams stop maintaining duplicate systems. The scope is organizational, not local.
A useful calibration before every story: could an SDE1 have done what you describe? If yes, find a better story. This sounds harsh until you realize you've spent three weeks preparing a story that describes fixing a bug in a service only your team uses.
The Bar Raiser Round
The bar raiser is an experienced Amazon engineer, typically senior or principal, with no stake in hiring for your specific team. Their role is explicitly to hold the bar for the level, not to help the hiring team fill a position. They have formal veto power. So does the hiring manager. Nobody else does. There's a full breakdown of how it works in the Amazon Bar Raiser guide.
The bar raiser's question isn't "is this person good?" It's "does this person raise the bar above the median current SDE3 at Amazon?"
Bar raiser rounds go deeper into a single LP story than you expect. They may spend 20 minutes on one answer, peeling back each claim layer by layer. What did you specifically do? What did the other team contribute? What would have happened if you hadn't acted? What were the exact numbers before and after? They also frequently combine a coding problem and a mini system design in the same session. The format is less predictable than the other rounds.
Practical prep: for every LP story you plan to tell, ask yourself whether you can survive ten minutes of follow-up on it. If the answer is no, either find a story you know more deeply or go dig up the numbers.
The bar raiser, somewhere around minute 15 of your Ownership story, asking for the exact P99 latency before and after your change.
How to Prep: Six to Eight Weeks
If you're currently employed and actively interviewing, six to eight weeks is enough if you're structured. That word "structured" is doing a lot of work in that sentence. It means no aimless LeetCode grinding. It means dedicated blocks, consistent narration practice, and stories that get sharper each week rather than just more rehearsed.
Weeks 1-2: DSA. Focus on graphs, DP, heaps. Twenty-five to thirty problems, all timed, all narrated out loud. Solving silently trains exactly the wrong skill for Amazon's format.
Weeks 3-4: System design. Two to three canonical designs per week (URL shortener, messaging queue, distributed cache, rate limiter). Practice on paper or a shared doc, not slides. Get comfortable with capacity math: storage, bandwidth, QPS estimates. Vary the requirements each time you run a design. What changes if write volume goes up 10x? What changes if the business needs multi-region?
Weeks 5-6: LP stories. Write out six to eight stories in full STAR format. Audit each for scope. How many teams were affected? What's the counterfactual if you hadn't acted? Do you know the specific numbers? Run practice sessions where someone interrogates each story for ten minutes straight.
Weeks 7-8: Full mock loops. One coding, one system design, and one LP session per week. Full timing. Video on. Run your LP stories in a voice mock interview at SpaceComplexity and explicitly ask the interviewer to follow up with "what specifically did you do?" and "what would have happened if you hadn't?" Those two questions find every gap faster than any other prep method.
Amazon's hiring timeline from phone screen to offer runs four to eight weeks. Expect gaps for scheduling. Don't let the waiting period turn into passive decompression.