Amazon Bar Raiser Coding Interview: What Changes

You're 15 minutes into an Amazon bar raiser coding interview. You've identified the pattern, your solution handles the examples, and you're about to submit. Then the interviewer changes a constraint. The array is now unsorted. The time limit drops from O(n log n) to O(n). Your original solution collapses, and this moment is exactly where the Bar Raiser's higher evaluation standard shows up.

What the Bar Raiser role actually is

Amazon's Bar Raiser is an independent evaluator assigned from outside the hiring team. They maintain the company's hiring bar by evaluating candidates without team specific bias, and they can veto any hire.

That veto works in both directions. A Bar Raiser can block a candidate that every other interviewer wants to approve. If the Bar Raiser sees genuine depth in a borderline candidate, that signal carries outsized weight too.

In practice, you won't always know which of your interviewers is the Bar Raiser. Amazon deliberately keeps this ambiguous during the loop. But the Bar Raiser always conducts at least one round, and that round frequently includes a coding problem.

The coding round looks identical to any other Amazon technical screen on the surface. The difference is in what happens after you produce an answer. A regular interviewer might move on once you've solved the problem. A Bar Raiser probes. They'll ask you to optimise, handle a new constraint, explain why your approach is correct, or walk through the failure case you didn't test. The follow ups are where the real evaluation happens. Your initial solution just gets you into the conversation.

Why the Bar Raiser interview tests broader

Every FAANG company has favourite pattern categories. Google leans heavily on predicate search (binary search on the answer space). Meta concentrates on sliding window and design problems. Amazon is different. Amazon tests the broadest range of patterns of any major company.

Across the problems tagged to Amazon on Codeintuition's platform, the coverage includes counting, fixed and variable sliding window, prefix sum, LRU Cache design, randomised set design, binary search, 2D binary search, staircase search, maximum predicate search, queue design, and backtracking. That's 11+ distinct pattern families, compared to Google's 7-8 and Meta's 6-7.

What this means practically: you can't narrow prep for Amazon the way you might for a Google interview. A Google candidate who deeply understands predicate search, counting, and graph patterns covers a significant portion of what they'll face. An Amazon candidate who goes equally deep on three pattern families still has blind spots across the other eight.

The Bar Raiser compounds this. Because the Bar Raiser isn't tied to the hiring team's domain, they can pull problems from any pattern family. Your preparation has to be wide enough that an unfamiliar category doesn't end the round.

(Worth noting here: Amazon's Leadership Principles play into every interview round, including the coding round. A Bar Raiser evaluates your communication and reasoning process alongside your solution. That's outside the scope of this article, but it means how you explain your thinking matters as much as the code itself.)

For a detailed breakdown of how Amazon's patterns compare to Google's and Meta's, see Amazon vs Google coding interview patterns.

How a Bar Raiser evaluates your coding round

Three signals separate a pass from a strong hire in a Bar Raiser coding round.

1. Clean thinking under ambiguity

The Bar Raiser gives you a problem with loosely specified constraints. Maybe the input isn't guaranteed sorted. Maybe the size could be zero. If you immediately ask clarifying questions, define your assumptions, and then proceed with a structured approach, that shows the reasoning Amazon values. Jumping straight to code without defining the problem space tends to reveal you're operating from memorised patterns rather than constructed reasoning.

2. Follow up handling

After you solve the initial problem, the Bar Raiser shifts the constraints. Can you adapt? If your solution relied on sorting, what happens when sorting isn't allowed? If your solution ran in O(n²), can you identify the bottleneck and improve it? The follow up tests whether you understand the mechanism behind your solution or just the solution itself.

This is where surface pattern recognition breaks down. If you solved the problem because you'd seen it before, you'll struggle to adapt when the constraints change. If you solved it because you understood why the pattern applies to this class of problem, the adaptation feels natural. Learning science calls this far transfer: applying knowledge in a context you haven't practised in.

3. Evidence of deep understanding

The Bar Raiser listens for explanations that go beyond "I'm using a hash map here." They want to hear why a hash map is the right choice. What invariant does it maintain? What would break if you used an array instead? A candidate who can articulate these tradeoffs is the kind of engineer who raises the bar for the existing team.

Common mistakes in Bar Raiser coding rounds

Most candidates don't fail the Bar Raiser round because they can't code. They fail because their preparation optimised for the wrong thing.

Solving silently

The Bar Raiser is evaluating your reasoning, not just your output. Candidates who code in silence for 10 minutes and then present a finished solution give the interviewer almost nothing to evaluate. You've produced an answer, but you haven't demonstrated how you think. Narrate your approach as you go. State what pattern you're considering and why. Call out the tradeoff you're making when you choose a hash map over a sorted array. If you hit a dead end, say so and explain what made you reconsider.

This isn't about performing confidence. It's about making your decision process visible. The Bar Raiser can't give you credit for reasoning they didn't observe.

Over-optimising the first solution

Some candidates try to produce the optimal solution immediately. They spend 15 minutes thinking before writing a single line, then run out of time when the follow up arrives. A better approach: get a correct O(n²) or O(n log n) solution working first. Confirm it handles edge cases. Then, when the Bar Raiser asks you to optimise, you've got a working baseline to improve from. This also gives you something concrete to discuss during the follow up rather than starting from zero.

Treating the follow up as a new problem

When the Bar Raiser changes a constraint, many candidates mentally discard their previous solution and try to solve a fresh problem from scratch. That's almost always the wrong instinct. The follow up is designed to test whether you understand the structural relationship between the constraint and your approach. Ask yourself: which part of my solution depended on the constraint that just changed? If the problem required sorted input and your solution used binary search, the follow up removing the sorted guarantee means you need to replace the search mechanism, not the entire algorithm.

The candidates who handle follow ups well are the ones who can isolate the dependency between a constraint and a specific part of their solution.

Ignoring edge cases until asked

Bar Raisers notice when you test your solution against the happy path and stop. Empty arrays, single element inputs, duplicate values, integer overflow boundaries, these aren't afterthoughts. Proactively walking through at least two edge cases before the interviewer prompts you signals thoroughness. It also protects you from a follow up that targets exactly the edge case you skipped.

Preparing for a Bar Raiser interview

Amazon's breadth requirement changes how you should study. The typical approach to FAANG preparation is to go deep on two or three pattern families and hope the interview lands in their zone. For Amazon, that strategy has a lower hit rate than for narrower companies.

The study method that actually addresses this is interleaving. Instead of spending a week entirely on sliding window, then a week on dynamic programming, then a week on graphs, you rotate between pattern families within the same study session. Research on interleaved practice consistently shows that mixing problem types during study improves your ability to identify which pattern applies to a new problem. That identification skill is exactly what the Bar Raiser's follow ups test.

Consider LRU Cache, the single most cross company tested problem in Codeintuition's data, tagged at 19 companies including Amazon. Solving it requires composing two data structures: a hash map for O(1) lookups and a doubly linked list for O(1) eviction ordering. That composition isn't obvious if you've studied hash maps and linked lists in isolation. It becomes clear when you've practised identifying which data structure properties a problem requires, then selecting structures that provide those properties.

The Bar Raiser follow up on LRU Cache might be: "What if each entry needs a time to live expiration?" Now your linked list ordering changes from access recency to expiration time, your eviction logic shifts, and you need to decide whether to eagerly clean expired entries or lazily evict them on access. If you understood why the doubly linked list was there (maintaining an ordering invariant for O(1) removal), the TTL adaptation is a modification to the ordering criterion. You don't have to redesign the whole thing.

That's the gap the Bar Raiser is probing. Can your understanding stretch to a constraint you haven't seen before?

What happens on the day of the loop

Knowing how the full interview day works removes a layer of uncertainty that has nothing to do with your technical ability.

Amazon's onsite loop typically includes 4-5 rounds spread across a single day (or consecutive virtual sessions). One round is system design for senior candidates. Two or three are coding rounds. One is a behavioural round focused on Leadership Principles. The Bar Raiser participates in at least one of these, and you won't know which one until after the process is over.

Each coding round lasts about 45 minutes. The first 5-10 minutes are typically spent on introductions and the problem statement. You'll have roughly 25-30 minutes for the initial solution, and the final 10-15 minutes are where follow ups happen. That time pressure is real. If your initial solution takes 35 minutes because you were chasing the optimal approach from the start, you've left no room for the follow up that actually determines the Bar Raiser's assessment.

Between rounds, you'll get short breaks. Use them. Don't mentally rehearse what just happened. Each round is evaluated independently, and the Bar Raiser considers your performance across the full loop, not just their own round. A strong follow up in round three can balance a shaky start in round one.

One detail candidates often miss: the debrief happens without you. All interviewers, including the Bar Raiser, meet afterward to discuss each candidate. The Bar Raiser's opinion carries disproportionate weight because they're evaluating against Amazon's company wide bar, not the hiring team's immediate need. If there's a disagreement between the Bar Raiser and the hiring manager, the Bar Raiser's veto stands.

Three months from now

The Bar Raiser coding round isn't a fundamentally different interview format. It's the same problem solving test with a higher evaluation standard and broader pattern coverage. Preparing for it means building two things that usually get skipped: pattern breadth across families, and the ability to explain why your approach works when the constraints shift.

Codeintuition's learning path covers 16 courses across 75+ patterns, with each pattern's identification triggers taught explicitly before problem practice begins. Amazon's breadth requirement makes that identification layer more valuable than it is for narrower companies. The free Arrays and Singly Linked List courses cover 15 patterns across two pointer, sliding window, and linked list families. For Amazon's most tested patterns like counting and prefix sum, the Hash Table course teaches each from first principles with the pattern recognition phase that makes follow up adaptation possible.

For the complete preparation framework, including how to structure your timeline across all FAANG companies, see the FAANG coding interview preparation playbook.

Three months from now, you're in the actual Bar Raiser round. The interviewer changes a constraint on the problem you just solved. You don't freeze. You trace the constraint change back to the invariant, explain what breaks, and adjust the mechanism. The Bar Raiser writes one word in their notes: hire.