How to Interview Across Timezones

We lost a backend engineer we'd have hired in a heartbeat because our interview process took nineteen days. She was in Lisbon, our hiring panel was scattered across the US and Singapore, and every stage waited for the next available person in the next available timezone. Recruiter screen on a Monday. Technical screen the following week, because the interviewer's mornings were her evenings and only two slots lined up. Then a panel that took four days to assemble, then a debrief that sat in a Slack channel over a weekend while the deciders were offline. On day nineteen we sent the offer. She'd signed somewhere else on day twelve. Her note was polite and a little baffled: she'd assumed we weren't that interested.

That's the part that stung. The role was open, the panel liked her, the offer was strong. None of it mattered, because a distributed hiring loop had quietly stretched a two-week process into three, and she read the silence exactly the way anyone would.

The interview loop is a chain of appointments across nights

An interview process isn't one event. It's a chain of scheduled human touchpoints, each one depending on the last, and on a distributed team every link in that chain has a good chance of crossing a night.

Co-located, this is invisible. The recruiter screens someone Tuesday, walks over to the hiring manager Wednesday, and a panel gets booked for Friday because everyone's in the same building on the same clock. The whole loop fits in a week without anyone thinking about it. Now spread the panel across nine timezones. The recruiter in New York screens the candidate. The technical interviewer she needs next is in Bangalore, and their only shared window is a narrow band at the edges of both their days. Scheduling that one conversation eats two or three calendar days before it even happens. Stack four or five stages like that and the gaps between them, not the interviews themselves, become the whole timeline.

This is the same round-trip tax that makes a pull request wait days for review, pointed at hiring. Each stage is a handoff to the next person, and each handoff is priced in whatever overlap those two calendars share. The difference is that a delayed PR just sits there patiently. A delayed candidate does not.

The delay costs you the candidate, not the calendar

Here's what makes hiring different from every internal process you run across timezones. The person in the loop doesn't work for you. They have other options, they're often talking to two or three companies at once, and they're reading your speed as a signal the entire time.

Inside your team, a slow loop is a cost you absorb. A feature ships late, a decision waits a week, and everyone grumbles but nobody leaves. In hiring, the slow loop doesn't stay inside your walls. Every day of quiet is a day a competitor with a tighter process is moving the same candidate toward an offer, and a day your candidate is quietly deciding you're lukewarm. Good people are the ones with options, which means good people are exactly the ones you lose to a nineteen-day loop. The candidates who wait around through three weeks of silence are disproportionately the ones nobody else is chasing.

So the latency does more than annoy people. It actively selects against the hires you most want. That reframes the problem: speed in a distributed hiring process isn't a polish item you get to once operations run smoothly. It's the thing standing between you and the person you're trying to hire.

Compress the loop and batch the interviews

The instinct when a process is slow is to run the stages in parallel or cut a stage entirely. Sometimes that's right. Usually the bigger win is simpler: stop sprinkling the interviews across the calendar and pack them into as few days as you can.

A five-stage loop where each stage gets scheduled independently is five separate rounds of timezone Tetris, each adding its own multi-day gap. Instead, treat a candidate's interview day like the scarce thing it is and book the block up front. When someone clears the screen, get the panel's availability in one pass and lock a single day, or two adjacent ones, where the candidate does the technical, the system design, and the manager conversation back to back. Yes, that's harder to coordinate across timezones than a co-located panel. But you pay the scheduling cost once instead of four times, and the candidate goes from screen to decision in days rather than weeks.

Batching also protects the candidate, who is very likely still working a full-time job while interviewing with you. Asking someone in a distant timezone to carve out five separate evening slots over three weeks is its own quiet way of losing them. One concentrated block respects their time in a way a drawn-out drip never does. Whatever scheduling discipline you already apply to the meetings your own team can't avoid, candidates deserve it more than your standup does.

Make the debrief async so the loop doesn't stall on a meeting

The single most common place a distributed loop dies is the debrief. The interviews went fine. Now four people who share almost no waking hours are supposed to get in a room, compare notes, and decide. That meeting is nearly impossible to schedule, so it slips to "next week when we're all around," and the candidate sits in limbo through the exact stretch when a competing offer lands.

Kill the synchronous debrief. Have every interviewer write their assessment within a few hours of their own interview, in a shared doc: a clear recommendation, the evidence behind it, and the specific reservations they want the others to weigh. Written independently, before anyone reads anyone else's, so you get honest signal instead of the loudest voice in the room anchoring everyone. Then one named decider reads the whole thing and calls it. This is just making the decision without booking a meeting, applied to the highest-stakes decision your team makes all quarter. A written debrief that closes in a day beats a live one that waits for an overlap window that may not come until the candidate is gone.

Don't make the candidate do the arithmetic

A candidate who gets an invite for "2pm" and has to figure out whether that's your 2pm or theirs is a candidate you've already started to lose a little. It reads as careless, and worse, it's the kind of small ambiguity that ends with someone joining a call an hour late through no fault of their own, in the one context where a first impression actually counts.

Every time you send a candidate lands in their inbox, write it in their timezone, or in both, with the zone spelled out in full. Not "PT," which assumes they know your abbreviations, but "3:00pm in Lisbon (your time)." Use scheduling tools that render slots in the candidate's local clock automatically. This is the hidden cost of timezone ambiguity at its least forgiving, because internally a misread time wastes ten minutes, while in a hiring loop it can cost you the hire, and at minimum it costs you their confidence that you've got your act together. The math is trivial. Making the candidate do it is the tell.

Keep the candidate warm in the dead time

Even a tight loop has gaps. There will be a couple of days where nothing is scheduled and the candidate is waiting. Across timezones those gaps feel longer than they are, because a message you send at the end of your day lands in the middle of their night and the reply comes a full day later.

Fill the silence on purpose. A short, specific note beats a vague one: "Panel's this Thursday, we're aiming to have a decision to you by Monday your time." That one sentence does an enormous amount of work, because the thing that makes a candidate walk isn't usually a slow process, it's a slow process they can't see into. Silence gets read as disinterest, and disinterest gets read as permission to sign elsewhere. Setting an explicit expectation for when you'll be back to them is the hiring version of a clear response-time contract, and it buys you patience you would not otherwise have earned.

What still has to happen live

None of this means run the whole thing async. Some parts of hiring genuinely need to be synchronous, and pretending otherwise is how you hire the wrong person fast. The actual interviews should mostly be live, because you're assessing how someone thinks in real time and reacts to a follow-up they didn't see coming, which a take-home can't show you. The final conversation, where a candidate asks the hard questions about the team and you try to close them, is worth defending a real overlap hour for. What you make async is the connective tissue between those moments: the scheduling, the debrief, the status updates, the parts where a live meeting adds delay without adding signal. Compress everything that's coordination, protect the few things that are genuinely judgment, and the loop that used to take three weeks closes in one. The candidate you wanted is still available when it does. Everything here about coordinating your own team applies double to the candidate deciding whether to join a distributed one, because your interview process is the first honest demo of how the team actually runs.

Give Every Interview Invite a Clock the Candidate Reads Right

A hiring loop is the worst place for a misread time, and "2pm" means four things to four people. Timely converts every time mention in Slack to each person's own clock automatically, so when your panel coordinates a candidate's block or a "let's sync on the debrief at 4pm" lands across a spread-out team, nobody schedules against the wrong hour and no candidate slips through a gap you didn't see.

Add Timely to Slack — Free · See how it works