I designed one scheduling framework to unify all interview types. Built to handle formats from single phone screens to large-scale multi-candidate events, each with different constraints, roles, and coordination needs, and scale toward full agentic automation.
Role
I defined the framework and drove event scheduling as the first use case, working closely with engineering, research, and product across talent acquisition. I also shaped how AI integrates into the work.
Scope
Framework designed to scale from single candidate interviews to large-scale multi-candidate events. Built alongside active legacy systems without disrupting existing workflows.
Outcome
Set the product direction for interview scheduling at Amazon.
Event scheduling shipped first, replacing 8 tools with one and reducing scheduling defects by [X]%.
Single loops and other interview types follow on the same foundation.
Slow, manual, and exhausting
Scheduling at Amazon covered far more than interviews, and all of it ran on people.
A scheduler pieced every session together by hand across 6+ disconnected systems, and the same willing interviewers got asked until they burned out. The biggest events multiplied everything. One change could ripple across dozens of people, and someone had to catch every ripple by hand.
6
disconnected systems across scheduling
95%
of the work happening in spreadsheets
70%
of scheduling done through manual steps
6
out of 10
average recruiter satisfaction score
Built on a shared data layer across interview types, validated through interactive prototypes before committing to production.
Mapping shared logic across tool silos
Having worked across event scheduling and other interview types firsthand, and consulting with designers across related scheduling domains, I looked for the common thread. The tools had evolved separately for specific needs, but the core work largely overlapped. Variations boiled down to two: pre-scheduled vs on-demand, and single vs multi-candidate.
Match & Schedule
Define targeted dates
Assign interviewers and shadows
Add Bar Raiser (BRRS or manual)
Define slot sequence
Configure breaks
Schedule debrief/pre-brief
Send invites to interviewers
Monitor & handle changes
Track interviewer responses, follow up on non-responses, find replacements for declines
Send candidate confirmation
Handle reschedules (interviewer declines, candidate requests, competency changes)
Update calendar invites with changes
Defining the foundation
This data model is what lets the same framework produce different workflows and interfaces depending on scale and situation. Rather than organizing by interview type, I separated the stable foundation from the per-instance inputs from the system's actions. It became the foundation for one framework that handles every interview type, and the substrate for agentic scheduling.
What's reusable
Reusable, defined at the job code level
Session sequencing
can be ai-assisted
Parallel (event) or sequential (loop), applied automatically from context
Competency mapping
can be ai-assisted
Ensures every required skill is covered across sessions
Format rules
can be automated
Sets duration, format (1:1 or panel), and mode (virtual or in-person)
What varies
Changes per situation
Interviewer pool
can be ai-assisted
Auto-derived from requirements, refined by real-time availability and interview work load
Candidate constraints
Human input
Availability, accommodations, pipeline stage
Context
Human input
Scale (phone screen to 40-person event), urgency (first available vs specific executives), mode (schedule around candidate vs pre-build slots)
What the system handles
System responds accordingly
Match and balance
can be ai-assisted
Pairs interviewers to slots based on availability, qualifications, and pool load
Send confirmations and track
can be automated
Sends invites, tracks responses, follows up when interviewers don't respond
Handle exceptions
Human input
Manages declines, competency changes, and late additions
The same structure applies whether scheduling a phone screen or a 40-person event. What shows up depends on the scale and situation
Where AI fits in complex scheduling
The same foundation also defined where AI fits. Leadership expected a chatbot-first experience. I pushed back: scheduling is not a linear task, and a conversational interface can't surface the full picture a coordinator needs to make tradeoff decisions in real time. I positioned AI as a layer that works alongside the tool.
AI handles routine requests through chat
AI reacts to events that need attention
Building the framework on top of the data model
The data model gave us the structural answer, but an answer on paper isn't a framework. The framework is the set of decisions that determine how the data model shows up in practice, across every scheduling situation. That's what this part of the work figured out.
01 / First direction
Two views split by scale
My first direction built two scheduling views sized to the situation. A per candidate view handled single candidate situations: phone screens, recruiter calls, and single loops. An event coordination view handled multi candidate events. Separating the two kept each focused, so neither had to carry the other's weight.
I built an interactive prototype to stress test it in cross functional workshops. It worked conceptually, but didn't hold in practice. Walking through real scenarios surfaced the underlying issue.
Simplified view of the initial prototype: one candidate scheduling view for all interview types, with a separate layer for event coordination
Illustrating why the direction didn't hold in practice
02 / The shift
One experience that adapts
One scheduling experience driven by the shared data model. It reads the data model and composes the experience from what the schedule contains, expanding for scale, handling shared interviewers, and applying org-specific rules.
Static mocks couldn't validate a framework. Stakeholders needed to experience the tool adapting across scenarios. I built a second interactive prototype and roadshowed it across talent acquisition teams, including interview types we hadn't built for yet. It held. This became the product direction.
One framework composing every scheduling case from the same data model
A subset of the prototype, showing the framework across two situations
Shipping the hardest case first
Event scheduling was the first use case to ship — multiple candidates on one coordinated schedule, where a change to one part can affect the rest. The strongest test for the framework, and the research showed why:
103 min average time to schedule one event of 5 candidates
51% said securing interviewers is their biggest frustration
70% of scheduling time spent in spreadsheets and manual workarounds
Designing for this meant holding three tensions at once:
Flexibility vs standardization
Teams have legitimate reasons to operate differently. The design needs to support those variations without becoming a different tool for each team.
Enabling parallel work
Interviewer securement, candidate assignment, and logistics happen at different speeds by different people. A change to one can affect the others.
Scheduling interdependencies
Interviewers and candidates are connected across sessions. A single change creates a cascade the design has to make visible and actionable.
A / Pain point
Locking in interviewers causes delays and constant back and forth
Locking in interviewers involved a mix of offline agreements, email requests, and follow-ups. Many went unanswered or got declined, pushing the schedule back.
I designed one place where recruiters and schedulers lock in interviewers two ways: pick directly, or open up signup, a new path I introduced where interviewers opt in based on eligibility and workload. Signup launched first for events, designed to extend to other interview types.
Recruiter/Scheduler view
Interviewer view
Interviewer view
Scheduler view
The RC acts on declines with full context
B / Pain point
Schedule changes with invisible ripple effects
Schedulers had no complete picture of whether an event was on track. When an interviewer declined or a candidate needed to move, the scheduler had to figure out which sessions were affected, with no tools connecting those relationships.
I designed the scheduling experience around three principles: consistency by default, exceptions that don't break the structure, and complexity surfacing only where it matters. When something changes, the system shows what's affected and what to do next.
Scheduler view
Outcome
Event scheduling shipped first, with the framework setting the foundation for what comes next.
8 → 1 disconnected tools consolidated into one scheduling experience
103 min → [X] min average scheduling time per event of 5 candidates
[X]% reduction in scheduling defects
Where the framework goes from here
Each new scheduling type becomes a configuration of the same underlying model rather than a standalone solution. Single loops, phone screens, and other interview types build on what's already there instead of starting over.
Now partnering with the science team on agentic scheduling, with early results reducing manual scheduling from 30 minutes to under 5. The structured context captured in the system is what makes that possible. The foundation was designed to support it.
Built by Fangru Wu 2026
Craft matters