The Amazon bar raiser interview is one of the regular rounds in your loop. It’s run by a trained interviewer from another team. You usually can’t tell which round it is. Guessing doesn’t help much. The Bar Raiser’s real power sits in the debrief, where they guide the discussion of every interviewer’s notes. Bill Carr, a former Amazon vice president, says they can also veto a hire. So the Bar Raiser judges your loop as a set of notes read side by side. That makes consistency the main risk. Say you describe your role in a project one way in the morning and another way after lunch. The debrief will put those two notes next to each other. The fix is to prepare the loop as one file. Fix your role, your numbers and the decision you owned for each project. Then use the same facts in every round. Below is one Android project told across three rounds, with a prep sheet and lines to use.
The Bar Raiser is an interviewer from another team with a vote in the debrief
Amazon’s own page on what a Bar Raiser is gives three jobs. They interview the candidate. They drive a data-driven hiring decision with the hiring manager. And they coach other interviewers. The page counts more than 3,600 Bar Raisers. They include software engineers, product managers and people from other roles. The page has no visible date.
The debrief part is where the role differs from the others. Carr co-wrote Working Backwards with Colin Bryar. In an April 2021 summary of the book, he wrote that the Bar Raiser guides debrief meetings. He added that this person “can also veto a hire.” Amazon’s own page puts it more softly. It says the Bar Raiser makes final hiring decisions alongside the hiring manager.
Amazon’s page doesn’t describe any way to tell which interviewer is the Bar Raiser. The page says Bar Raisers include software engineers. Nothing on it says the Bar Raiser asks only about Leadership Principles. It’s more useful to prepare for what they will read after you leave.
Amazon gives each interviewer a different slice of you
Carr’s summary describes the setup. Each interviewer covers specific criteria only. The criteria are divided across the loop. Amazon’s SDE II interview prep page says the same for engineers. Some interviewers are assigned technical competencies. Others are assigned competencies from the Leadership Principles. The SDE II loop has four 55-minute interviews. Each interviewer typically asks two or three behavioral questions too.
That split has a side effect. No single interviewer sees your whole story. The coding interviewer hears about your project for two minutes. The hiring manager hears about it for ten. Only the debrief puts those pieces together. The Bar Raiser is the person whose job is to ask whether they fit.
Amazon’s page quotes Annie Groeninger, a software development manager and Bar Raiser. Her debrief question is “What does Amazon miss out on if we don’t hire this person?” Every interviewer answers that from their own notes. If the notes disagree, the answer gets weaker.
One Android project told three ways in one loop
Here’s the running example. You moved an app’s checkout screen from XML views to Jetpack Compose. Crashes on that screen fell afterward. It’s your strongest project, so it comes up three times.
In the morning, the hiring manager asks a question about ownership. You say you led the migration and cut checkout crashes by 40%. Before lunch, the system design interviewer asks how you’d structure a checkout screen. You mention that your team lead chose the state architecture. You built the screens. In the afternoon, a coding interviewer asks about a time you dove deep. You say crashes dropped “by about half.”
Each answer is defensible on its own. But the debrief now holds three notes. One says you led the work. One says your lead made the main design call. One gives a different number for the same result. The Bar Raiser will likely ask which version is right. Nobody in that room can ask you.
The result could be a debrief note that reads “claimed ownership unclear” or “numbers inconsistent.” A missing detail leaves a gap in the notes. A contradiction gives the Bar Raiser a specific concern to raise.
Prepare for the Amazon bar raiser interview with a one-page loop sheet
The fix is a page you write before the loop and read before each round. List each project you might mention. For each one, fix four things. Those are your role, the number, the one decision you owned and what someone else decided. Here’s the sheet for the checkout project.
Project: checkout screen, XML to Compose (2025, 4 months) My role: built 6 of 8 screens; owned the rollout plan Not mine: state architecture (team lead chose single UiState + reducer) Number: checkout crash rate 0.9% to 0.5% of sessions over 6 weeks Measured by: Firebase Crashlytics, checkout screens only Decision I owned: staged rollout 5% / 25% / 100% behind a remote flag What I'd change: add screenshot tests before the migration, not after
The numbers here are illustrative, so use your own. Note one thing about them. 0.9% to 0.5% is a drop of about 44%. Pick one way to say it and keep it. “About 40%” in one round and “about half” in another can sound like two different results.
The “not mine” line matters as much as the role line. It lets you credit your lead in the design round without shrinking your role. And it stops you from over-claiming in the ownership round.
A sample answer that holds up when the Bar Raiser pushes
The Bar Raiser’s own round may go deeper on one claim. Amazon’s SDE II page says answers should include metrics or data where they apply. Expect a push on the source of a number. Here’s the checkout story, built from the sheet, with that push answered.
I built six of the eight checkout screens in Compose. I also owned the rollout. My lead chose the state architecture. We used a single UI state with a reducer. The decision I owned was rolling out in stages. It sat behind a remote flag. We went to 5% of users, then 25%, then everyone. Checkout crashes went from 0.9% of sessions to 0.5% over six weeks. That’s from Crashlytics, filtered to the checkout screens only. If I did it again, I’d write screenshot tests before the migration. We added them after. So we caught two layout regressions late.
The first two sentences fix your role and name what wasn’t yours. Any interviewer can write that down the same way. The middle gives one decision you owned and how it ran. The number comes with its source and its time window. So a “how did you measure that?” follow-up is already answered. The last part shows you can judge your own work. It’s the same answer in every round. Only the depth changes with the question.
How you choose and tell the story is the behavioral round’s job. Our post on reusing the same story across an interview loop covers giving one project different angles. The loop sheet sits under that. It keeps the facts the same while the angle changes.
If you notice a mismatch mid-loop, correct it out loud
Suppose you realize at lunch that you said “led the migration” in the morning. Don’t hope nobody compares notes. In the next round where the project comes up, correct it plainly. Try something like this.
Quick correction from this morning. I didn’t lead the migration. I built most of the screens and owned the rollout. My lead owned the architecture.
That puts a correction in a written note. In the debrief, the Bar Raiser can see you caught it yourself. Without it, the two notes just disagree.
Written notes decide the outcome at other companies too. Our post on why you can be rejected after a good interview covers that. At Amazon, the Bar Raiser is the person who lines those notes up.