Improving Bar Raiser scheduling

Every Amazon interview loop from L4 to L7 needs a Bar Raiser: a trained, neutral evaluator who protects the hiring bar. Matching one to a loop sounds simple. At Amazon’s scale, with 8,000 Bar Raisers across every time zone, it’s a hard scheduling problem, and the system built to solve it wasn’t working. I fixed the root cause, and time to secure a Bar Raiser dropped by more than half.

How Bar Raiser scheduling works

Bar Raiser scheduling isn’t a small operational task. It’s a system running at scale with real hiring impact: more than 8,000 Bar Raisers globally, around 324 loops scheduled a day, across APAC, EMEA, and the Americas.

In 2023 the team launched a scheduling system to automate this, with three actors who have to line up for any loop to get booked:

• Bar Raisers set their preferences. On a preference page, each Bar Raiser indicates availability, time zones, capacity, and competencies. Being a Bar Raiser is a second job on top of their real one, so most cap themselves at two or three interviews a week, and their availability shifts constantly.
• The algorithm recommends. It reads each Bar Raiser’s preferences, analyzes a loop’s requirements, filters 8,000 people down to the qualified few, and returns the top handful of recommendations in seconds. It’s only as good as the data it’s given.
• Recruiting coordinators schedule. Using the scheduling tool, they build the loop: match technical Bar Raisers to technical roles, find people free across time zones, and fit everything into a tight hiring window. They need the right Bar Raiser who will accept on the first try.

The problem

Since launch, the system got mixed feedback, and the data showed why. Bar Raisers were getting mismatched invitations they had to decline. Recruiting coordinators were spending too long hunting for someone who would say yes. It took 4.88 invites and 138 hours on average to secure a Bar Raiser, with a 40% decline rate against a 32% acceptance rate. People stopped trusting it and fell back on manual workarounds.

The system had all the right pieces. But Bar Raisers couldn’t fully express their preferences, recruiting coordinators couldn’t filter for what they actually needed, and the algorithm was stuck in the middle doing its best with thin information.

How I worked

1. 01Learn where it breaksRan focus groups and voice-of-customer sessions with our PM and the BR program team to find where scheduling actually failed.
2. 02Ground it in what’s possibleWorked with engineers to understand what the system could and couldn’t do, which shaped the concepts worth pursuing.
3. 03Prioritize togetherChose where to focus as a team, weighing the pain research surfaced against what was technically feasible to ship.
4. 04Design, test, shipDesigned, tested, and refined three changes, then shipped them: a new preference page, a scheduling filter, and automated competency matching.

What research surfaced

Working with our PM and the Bar Raiser program team, we ran four focus groups with 21 recruiting coordinators across lines of business, plus a voice-of-customer session with experienced Bar Raisers. Three findings reframed the problem.

“Available that day” isn’t how scheduling works. The algorithm recommended anyone with at least an hour free on a given day. But coordinators are fitting five interviews, including the Bar Raiser, into one or two days, aligning interviewers, the candidate, time zones, and pre-brief and debrief times. A Bar Raiser with general Tuesday availability is useless if the only slot that works for everyone else is 2 to 3 PM.

I only get 4 or 5 options, and none of them is available for the time I’m actually trying to book. Recruiting coordinator, research session

Without precise filtering, coordinators resorted to hacking the system, changing time zones and refreshing pages to shake loose different results. Many admitted to using the tool just to hit their utilization target, then switching to manual methods they trusted more. That told us the real problem was trust.

The system assumed one size fits all. Underneath the specific complaints was a structural gap: the original design treated every Bar Raiser as interchangeable, so coordinators had no way to steer the match toward what a given role actually needed. Different orgs and roles have real, specific needs, from legal and security-cleared roles to language-specific loops, and the clearest case was technical roles. For an SDE loop, a coordinator needs a Bar Raiser who can assess coding or system design, but there was no lever to ask for that. The mismatches drove declined invites and delays, and left coordinators doing the matching in their heads.

Preference settings couldn’t capture real availability. From the Bar Raisers’ side, the controls were too blunt. They couldn’t express different times on different days, varying weekly capacity, or specific competencies. Reserved time slots had 7% adoption because the all-or-nothing model didn’t match how people actually work. And there was no prompt to update preferences, so the algorithm ran on stale data, feeding the 40% decline rate.

Decisions behind it

Research surfaced the problems. These are the calls that turned them into a design, each worked out with product, science, and engineering.

• Put control back in human hands

  The system matched everyone the same way. Should it just infer the right match on its own?

  It could have stayed automatic, but coordinators had already lost trust in a system that decided for them. So instead of a smarter black box, I gave both sides explicit controls: coordinators filter for the exact times and skills a role needs, and Bar Raisers describe how they actually work. A visible control people can adjust rebuilds trust in a way automation can’t.

• Match the mental model of a day

  How literally should the time filter mirror how coordinators actually book?

  I tested two ways of adding the filter and the visuals that highlight matching slots, and mapped the gaps between a Bar Raiser’s working hours, free time, and reserved time, so the result reads the way coordinators already think about a day, not the way the system happened to store it.

• Automate the skill match, don’t make people tag it

  For competency matching, should coordinators manually label the skills each role needs?

  Manual tagging would have added work and been applied inconsistently, and certification didn’t reliably reflect real ability. So the match runs off job-family data the system already holds, surfacing Bar Raisers who can actually assess a role without asking coordinators to do extra classification.

What I designed

The fix gave coordinators and Bar Raisers a way to express the specificity the system never let them have. Coordinators could finally steer the match; Bar Raisers could finally describe how they really work. It shipped as three changes.

• A redesigned Bar Raiser preference page. Real control over availability: multiple configurations for different days, flexible reserved time slots with expiry notifications, competency preferences, and a simpler save flow (removing the auto-save that had been causing confusion).
• A time filter in the scheduling tool. Coordinators specify the exact slots they need a Bar Raiser for, across the loop, pre-brief, and debrief, and the algorithm only recommends people free at those specific times.
• Automated competency matching. The system matches a role’s needs against what a Bar Raiser can assess, so an SDE loop surfaces people who can actually evaluate coding, with no extra tagging from the coordinator.

The outcome

The system moved on every measure that mattered.

• 53% less time to acceptance, from 138 hours down to 65.
• 28% fewer invites per hire, from 4.88 down to 3.52.
• 5.25-point lift in adoption, from 65.85% to 71.10%.
• 118,501 unique loops and 333,461 Bar Raiser invitations supported.

Shipped through 2025. Metrics tracked January to October.

This is the best, most productive year in terms of progress. TA change leads

The changes have significantly enhanced our scheduling and improved our workflow efficiency. Recruiting coordinator

This was a deliberately targeted fix. In 2025, without introducing any AI, the goal was to unblock the biggest pains by giving people better controls, where the most friction was felt. It worked, and it set up the next question I’m working on now: not just better controls, but a smarter, more automated match that does more of this work for people. Earning back trust first is what makes that next step possible.