Async Hiring Sprint: Hire Faster Without Burning Founder Hours

I used to spend 8–10 hours a week on hiring calls. Phone screens, first-round interviews, second-round interviews, “culture fit” conversations — all scheduled around the candidate’s availability, which meant my calendar looked like Swiss cheese. Multiply that across two or three open roles and you’ve effectively hired a part-time job: interviewing people for the privilege of doing more interviewing.

The worst part wasn’t the time. It was the signal-to-noise ratio. After a 45-minute call, I’d have a gut feeling and a page of hastily scrawled notes. The candidate who was charming on Zoom might completely fall apart on the actual work. The quiet one who seemed uncertain might have been the best operator in the stack. Live interviews reward performance, not competence — and as a founder, I can’t afford to optimize for the wrong thing.

What async hiring actually is

Async hiring means replacing most live interactions with structured, asynchronous steps. Instead of scheduling five calls to figure out if someone can do the job, you design a sequence where candidates demonstrate their thinking, their communication, and their actual skill — on their own time, reviewed on yours.

This isn’t about being impersonal. It’s about being deliberate. When I built out systems at BestSelf, the principle was always the same: design the process once, run it repeatedly, and let the system filter so you don’t have to. Hiring should work the same way.

For small teams especially, async hiring is a force multiplier. You don’t have an HR department screening candidates for you. You don’t have a recruiting coordinator blocking out interview panels. It’s you, maybe one other person, and a pile of applications. Async hiring lets you evaluate 30 candidates in the time it would take to interview 5.

The 4-step sprint

I run this as a sprint — start to finish in about two weeks. Four steps, each one designed to filter and build context so that by the time you actually talk to someone, you already know they can do the work.

Step 1: Record a Loom overview of the role

Before candidates apply, I record a 3–5 minute Loom video walking through the role. Not a polished recruitment ad — a real, first-person explanation of what the job is, what the team looks like, and what success means in the first 90 days.

Here’s what I cover:

What the company does and where we are right now. Not the mission statement — the actual situation. “We’re a team of 8, we do $X in revenue, and this role exists because Y.”
What this person will own. Not a list of responsibilities — the outcomes. “You’ll own our email marketing. That means campaign strategy, list segmentation, and hitting a monthly revenue target from email.”
What the day-to-day looks like. Tools, communication rhythm, how the team works. I mention that we’re async-first and what that actually means in practice.
What I’m not looking for. This is the most underrated part. Saying “this isn’t a management role” or “we don’t need someone who’s done this at a Fortune 500” saves everyone time.

The Loom does two things at once. First, it self-selects. People who watch the full video and still apply are already more engaged than someone who spray-applied to 40 job posts. Second, it gives candidates real context, which makes every subsequent step higher quality.

I send the Loom link in the job listing itself. If someone applies without referencing anything from the video, that tells me something too.

Step 2: Collect a written response

Instead of a phone screen, I ask candidates to answer 3–4 written questions. These aren’t trick questions or brain teasers. They’re designed to show me how someone thinks and communicates in writing — which matters a lot when your team is remote and async.

The questions I typically use:

“What about this role caught your attention, and what’s one thing you’d want to change about how we described it?” This filters for people who actually read the listing versus those who are copy-pasting cover letters.
“Describe a project where you had to figure something out without much guidance. What did you do, and what was the result?” I’m looking for resourcefulness, not credentials.
“What’s a tool or process you introduced at a previous job that made things work better?” This tells me if someone is a systems thinker or just a task executor.
A role-specific question. For a content marketer, it might be: “Pick one of our existing blog posts and tell me what you’d change and why.” For an ops person: “Here’s a process that’s broken — sketch how you’d fix it.”

I give candidates 48 hours and a soft word limit (500 words total, not per question). The constraint is intentional. I want to see if they can be concise and clear. The best people I’ve hired — including several I found using the approach in my longer hiring guide — consistently wrote responses that were direct and specific, not padded.

I review these in batch, usually in a single 90-minute session. No scheduling. No small talk. Just signal.

Step 3: Run a paid test project

This is the step most companies skip, and it’s the one that matters most.

I give finalists a small, real project that mirrors actual work they’d be doing in the role. It’s scoped to take 2–4 hours, and I pay for it — typically $150–$300 depending on the role. Last time I hired a project manager, I gave three finalists a messy brief and asked them to turn it into a project plan with milestones and a risk list. The differences were enormous. One person returned a polished Notion doc with clear owners and dependencies. Another sent back a bullet list that could have been written in five minutes.

Paying for the test project is non-negotiable for me. If the work is valuable enough that I’m using it to make a hiring decision, it’s valuable enough to compensate. It also widens the pool — strong candidates with other options won’t do free work for a company they don’t know yet.

What I’m evaluating:

Quality of thinking, not polish. Did they identify the right problems? Did they make reasonable assumptions and state them?
Communication. Did they explain their approach, or just dump a deliverable?
Speed and scope management. Did they stay within the time box, or did they gold-plate? Both extremes tell you something.

This step alone has saved me from at least three bad hires. The gap between “talks a good game” and “does good work” shows up here every single time.

Step 4: One 30-minute final conversation

By this point, I’ve seen how someone writes, how they think, and how they execute. The final call isn’t an interview — it’s a conversation between two people who already have context.

I use the 30 minutes to cover:

Anything that came up in the test project. “Walk me through why you structured it this way” or “I noticed you flagged X as a risk — tell me more about that.”
Working style and logistics. Time zone, availability, how they prefer to communicate, what their ideal feedback loop looks like.
Their questions. By this stage, good candidates have specific, informed questions. If they’re still asking “so what does the company do?” after watching the Loom and completing a test project, that’s a clear signal.
Compensation and timeline. No reason to dance around it. I state the range, ask if it works, and discuss start dates.

Thirty minutes is almost always enough. I’ve occasionally extended to 45, but never needed a second call. When you’ve already seen the work, you don’t need to manufacture scenarios to test someone in real-time.

What this replaces

The traditional process for most small companies looks something like: review resumes, phone screen (30 min), first interview (60 min), second interview (60 min), maybe a take-home assignment (unpaid, “should only take a few hours”), final interview (45 min), reference checks, offer. That’s 4–5 hours per candidate, minimum — and most of that time is spent on people you won’t hire.

The async sprint takes roughly 90 minutes of my time per candidate who makes it through all four steps. Most candidates self-select out by Step 2, which means I’m only spending real time on people who’ve already demonstrated they can do the work.

For context, the last time I ran this process, I had 80 applicants. Twenty submitted written responses. Six got the paid test. Two made it to the final conversation. Total time invested: about 12 hours across two weeks, including reviewing all written responses. Compare that to the 40+ hours I would have spent doing live interviews with even a fraction of those applicants.

When not to use this

Async hiring works best for roles where the work itself is async: content, marketing, operations, design, development, project management. Basically any role where someone will spend most of their time working independently and communicating through writing and documentation.

I wouldn’t use this process for roles where real-time chemistry and presence are the point — a co-founder, a head of sales who needs to run live demos, or a senior leader who’ll be in the room making decisions with you daily. For those, the live interaction is the test. You need to see how they handle ambiguity in real time, how they push back, how they read a room.

I also wouldn’t skip the final conversation entirely, even for the most async-friendly roles. Thirty minutes of face time catches things that writing can’t — energy, curiosity, whether you actually want to work with this person five days a week.

Build the system once

Hiring is one of those things that feels impossible to systematize because every role is different. But the structure — Loom, written response, paid test, final call — stays the same. I’ve used it for virtual assistants, content managers, developers, and ops hires. The questions change. The test project changes. The framework doesn’t.

If you’re still spending your weeks on back-to-back interview calls, try running one role through this sprint. Track the time you spend. Compare the quality of signal you get. I’d bet you end up with a better hire in half the hours — and your calendar might actually have room for the work that only you can do.