Amazon bar raiser coding interview

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. Engineers who immediately ask clarifying questions, define their assumptions, and then proceed with a structured approach show the reasoning Amazon values. Engineers who jump straight to code without defining the problem space tend to reveal they'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 trade-offs is the kind of engineer who raises the bar for the existing team.

Preparing for a Bar Raiser interview

Amazon's breadth requirement changes how you should study. Most engineers preparing for FAANG interviews 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?

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 most engineers skip: 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 identification 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.