Interview Scheduling

Context

Recruiting & Hiring is Frontline's applicant tracking system, and it was being rebuilt from the ground up. In the new version, each job posting gets a hiring funnel made of configurable stages, and one of those stage types is Interview. It existed as a label and nothing more — districts could move an applicant into it, then had to leave the product entirely to do anything about it: phone calls, email, a calendar tool, etc.

That mattered commercially. Roughly half the customers still on the legacy product used its interview management consistently, and a rebuild that couldn't do interviews gave them a reason not to move. This was a migration blocker before it was a usability problem.

Why Scheduling

The work started with generative research across districts, questions I wrote with the PM, calls she ran while I sat in and followed up as things came up. Districts didn't agree on what hurt most — one named room availability, another background check turnaround, another inconsistency between hiring managers. But scheduling kept coming back, and it sat upstream of most of the others. The typical version: a coordinator works out who should interview, chases their availability by phone or email, then contacts applicants once there's a window. If the two don't line up, or an interviewer drops, the whole sequence restarts. This amounts to a lot of manual, time-consuming work. The immediate thought is to integrate calendars into the product, however most districts don't have processes and infrastructure to make that useful.

AI Powered Prototype

I looked at how scheduling works in other products to understand what conventions users might be used to, then built a clickable prototype in Lovable — intentionally rough, closer to a wireframe than a finished interface, since its job was to give district administrators something concrete to react to. Building it in an AI tool meant I could rebuild it between sessions instead of between rounds, which turned out to matter.

Design Snag

The first version had the coordinator select interviewers and applicants on the same screen, poll everyone at once, and schedule wherever availability overlapped. The thought was to get both processes moving in parallel.

After two calls I realized we had missed some key things in our initial round of discovery. Interviews are almost always conducted by a panel, and getting a panel into one room is difficult, so districts book a single block and run every candidate through it back to back. Districts aren't interested in catering to candidates. If one or more can't make the times that the interviewers are available, they're out of luck. Additionally, the person setting up interviews often just tells the interviewers when to be there, and it's expected that they'll show up.

A flow that required a poll would be dead weight for a meaningful share of the customer base. I rebuilt the prototype between sessions and tested the new version on the remaining districts.

A quick fix

The new structure separated the steps: select interviewers and (optionally) poll their availability, select applicants, configure interview details (date, time, and location), set up confirmation emails, then review and send. This is where the scheduler's job ends. Applicants receive a link and book their own slot; once they do, the system sends confirmations to the applicant and the interviewers with a calendar file attached.

A New Problem

Splitting the steps introduced an ambiguity I hadn't anticipated. Users now saw two calendars in one flow — one for polling interviewer availability, one showing the slots offered to applicants — and several read the first as scheduling the actual interviews.

The fix was two-part: I replaced the tab structure with a stepper, so the sequence reads as a process with a position in it, and I made the poll step impossible to pass through passively. The coordinator either sends a poll or explicitly marks that no poll is needed. This forced users to slow down and understand the choice they were being given, which helped clarify the distinction between the two calendars.

Technical Snag

Every district has interviewers outside the system — a co-op employee with a district email who isn't in the staff directory, a partner district's administrator on a panel, etc. Sending them emails and giving them access to the polling interface added a good deal of work for Engineering. Their instinct was to build for the interviewers within the system and handle the rest later, which would have left coordinators doing the same manual email chase the feature exists to eliminate. I pushed for one path for everyone. Engineering landed on a single unauthenticated link, unique per recipient.

Outcome

85% of districts on the new Recruiting & Hiring are using the interview scheduler — close to universal adoption among the districts who have it. The old process, whether using the old R&H feature or some other solution, involved a lot of manual steps and time. The new process automates everything possible and cuts down the time scheduling takes on average. In testing, districts estimated this would take scheduling from a multi-hour task down to under half an hour. It also moved sales conversations, which was the original business case — the feature exists because its absence was a reason for legacy customers to stay put.

On Reflection

My first two testing sessions went to discovering that the coordination model was wrong. Finding it in testing beats finding it after a build, and I don't count the round as wasted, but I could have found it earlier with better questions in the generative round. A single sketch walkthrough with one district, no prototype, just a whiteboard of the sequence and a question about whether it matched how they work, would very likely have caught it before I built anything.