Amazon Onsite Interview Loop: What Each Round Tests and How to Prepare

You clear the recruiter screen, the online assessment, and the phone screen. Then you get the email: "We'd like to invite you to an interview loop."

Loop. Not "panel." Not "onsite." Loop. Amazon picked that word deliberately. The Amazon onsite runs 4 to 6 back-to-back 60-minute sessions in a single day. Each interviewer owns specific topics and specific Leadership Principles to probe. None of them compare notes beforehand. Somewhere in that loop, one person holds veto power over your offer. You will not know which one it is.

Good luck sleeping the night before.

What the Full Day Actually Looks Like

Most loops run virtually now. Amazon's 2025 return-to-office mandate covers full-time employees, not candidates. Expect Amazon Chime or a similar platform with a shared coding editor. If your loop is in person, the structure is identical: back-to-back sessions, different interviewers each time.

Plan for 4 to 5 rounds at L4 and L5, and 5 to 6 rounds at L6 and above. Each round is 45 to 60 minutes. Breaks exist between sessions but are not guaranteed.

This is not a polite suggestion. Eat before you start.

Every round follows the same skeleton: 15 to 30 minutes of behavioral questions tied to specific Leadership Principles, then 30 to 45 minutes of technical work. The ratio shifts based on round type. Coding rounds tilt toward technical. The Bar Raiser round inverts it entirely.

One thing that catches nearly every candidate off-guard: there is no dedicated behavioral round. Leadership Principles are baked into every single interview. You walk into what looks like a coding session. You answer LP questions for 20 minutes first. You were not warned. Budget mental energy for STAR stories across the full day.

The Two Coding Rounds Test More Than Code

Each coding round opens with LP questions, then moves to one DSA problem with 30 to 40 minutes of solving time.

Amazon targets LeetCode medium difficulty, with occasional medium-hard problems at L5 and above. Hard problems are rare. The goal is not to find who can solve the unsolvable. It is to watch how clearly and efficiently you reach a working solution and then optimize it. Two mediums solved with clear narration beat one hard solved in silence. This is a real, empirical fact that most candidates ignore while grinding Hards at 2 a.m.

The most common patterns by reported frequency:

Pattern	Common forms
Trees and graphs	BFS/DFS, level-order traversal, connected components
Arrays and strings	Two pointers, sliding window, prefix sum
Hash maps	Frequency counting, anagram detection, two-sum variants
Dynamic programming	1D at L4, 2D at L5+
Linked lists	Reversal, cycle detection, merge

Beyond correctness, interviewers score two things as explicit signals: whether you asked clarifying questions before you coded, and whether you tested your solution after writing it. A candidate who solves a medium perfectly but never clarifies edge cases and never dry-runs the code can still get a no-hire. A perfect solution in silence is a failed interview. The clarifying questions guide covers the technique problem-by-problem.

System Design: Stakes Scale With Your Level

The design round looks different depending on your level.

L4 candidates get a bounded problem: design a rate limiter, build a URL shortener. The question is whether you can define an API, sketch a coherent data model, and discuss basic caching and storage trade-offs without needing to be walked through every step.

L5 candidates face a mid-scale problem: a notification service, a search autocomplete system. You are expected to reason about horizontal scaling, sharding strategy, replication, and failure modes.

L6 and above get high-scale, ambiguous prompts. A real-time auction platform. A distributed messaging service. A feed ranking system. What separates hire from no-hire at this level is how you handle the ambiguity: whether you drive the conversation, surface trade-offs explicitly, and defend choices under follow-up pressure.

Regardless of level, the first five minutes carry outsized weight. Clarify the scale. Clarify the use case. Ask what success looks like. Interviewers watching design rounds consistently report that the sharpest candidates spend more time asking questions upfront. Interviewing.io published data on this and the gap is not small. The full Amazon software engineer interview guide covers what the system design rubric looks for at each level.

The Bar Raiser Round: They Won't Tell You Which Round It Is

Every loop includes one Bar Raiser. They are a trained Amazon interviewer from outside your team, outside your organization, with no stake in whether you get hired. Their job is to verify that you meet the company-wide bar for your level, not just the team's bar.

You will not be told which round the Bar Raiser is in. Amazon wants you to perform consistently rather than saving your sharpest material for the "important" interview.

So you have to assume every interviewer is the Bar Raiser. All five of them. At once. It is intentionally a little paranoid-making.

In practice, the Bar Raiser round runs almost entirely behavioral. While a typical coding round spends 15 to 20 minutes on Leadership Principles before moving to DSA, the Bar Raiser may spend 45 to 60 minutes on LP questions with follow-ups and never open a code editor. Some candidates expecting a system design session find themselves in 50 minutes of probing: "Why didn't you escalate earlier?" "What would you do differently?" "What did you get wrong?"

One STAR story can stretch across 15 to 20 minutes of follow-up questions. They are specifically testing for judgment, intellectual honesty, and whether your answers hold up when the follow-ups turn uncomfortable. A good story that falls apart under follow-up is worse than a medium story that holds. The Bar Raiser guide covers what they evaluate and the debrief power they hold.

Leadership Principles Run Through Every Single Round

Here is the part most candidates underestimate: the interviewers coordinate before the loop to divide Amazon's 16 Leadership Principles among themselves, and no two interviewers cover the same ones.

Sixteen principles. Five interviewers. Each one owns two or three. They gather evidence on those specific principles and no others. This is why your recruiter says "the interviewers won't know what each other asked." They literally do not, by design.

Two things follow from this. First, you need strong stories across all 16 LPs. Not just the three you feel most comfortable with. If you have a gap on Frugality or Hire and Develop the Best, someone in that room owns it and will find the gap. You will not know which question is coming for you. Amazon publishes the full list on amazon.jobs.

Second, your stories will be stress-tested. Prepare three levels deep: the STAR story itself, the reasoning behind the key decision, and what you would do differently in hindsight. That third layer is what the Bar Raiser is actually listening for. Most people prep one layer. That is why most people find the Bar Raiser uncomfortable.

What Happens After You Leave

The debrief session happens one to five business days after your loop. The Bar Raiser runs the meeting. Each interviewer presents their evidence, organized by LP dimensions and technical signals.

A unanimous hire vote is not required, but a Bar Raiser veto is final. Vetoes are rare in practice, but they happen, and no amount of team enthusiasm overrides them. The debrief is designed to surface disagreements and resolve them with evidence, not impressions. Interviewers who say "I thought they seemed strong" are pushed to point to a specific observed behavior. No behavior, no data, no hire.

Expect a recruiter call within a week to ten days of your loop.

How to Prep for the Amazon Onsite Interview

Technical half: Prioritize patterns over problem count. Aim for 60 to 80 LeetCode mediums across the five pattern families above, then add 20 to 30 medium-hard problems if you are interviewing at L5 or above. Filter by Amazon-tagged problems within the last six months where the data is available.

For system design at L5+, practice a consistent 45-minute structure:

5 minutes: requirements and clarifications
10 minutes: high-level design
15 minutes: deep dives on the hardest components
10 minutes: bottlenecks and scaling
5 minutes: trade-off discussion

Do not skip the trade-off conversation. It is one of the clearest signals separating a strong hire from a hire at senior levels. The person who says "we could do X or Y, here is why I would choose Y given our constraints" sounds like an engineer who has shipped things. The person who presents one option with no alternatives sounds like someone who has not.

Voice-based mock interviews under real time pressure train the skills that actually get scored. SpaceComplexity runs on-demand DSA mock interviews with rubric-based feedback across communication, problem-solving, and code quality, and identifies specific gaps during the interview rather than after. For the communication patterns that distinguish strong candidates, the technical interview communication guide is worth reading before your loop.

LP half: Build a story bank of 10 to 12 distinct stories before the loop. Do not reuse the same story across multiple LPs. For each one, prepare the STAR structure, know the alternatives you rejected and why, have a concrete result with numbers where relevant, and know what you would do differently. That last question comes up in the Bar Raiser round almost every time. Have the answer ready before you walk in.

The five LPs that appear most consistently in SWE loops: Customer Obsession, Ownership, Dive Deep, Deliver Results, and Bias for Action. Cover these first. Then build out the remaining 11 so you are not caught flat-footed.

Sixteen LPs is a lot. But so is a loop where every interviewer is testing a different one simultaneously without any of them knowing what the others asked. Prep accordingly.