I had only ever done synchronous loops before this one. The recruiter on the first call said "three of our five rounds are async; the other two are 45 minute live calls". I was skeptical. I had been told async interviews were a watered-down format. They were not. The loop was harder in some ways, easier in others, and the calibration was different in ways I want to write down. The company was a remote-first Series B (about 60 engineers, distributed across nine timezones, US-headquartered legally but no physical headquarters). The role was senior backend.

The 11-day rhythm

Five rounds across 11 days. The async rounds had soft deadlines ("please return your response within 3 business days, but we are flexible"); the live rounds were on calendars in the normal way.

day 0    recruiter call (live, 30 min)
day 2    written take-home: design doc, no code (async, due day 5)
day 6    loom-video round: walk us through the design doc + answer 4 follow-up questions (async, due day 8)
day 9    live coding round (45 min, video)
day 10   live behavioral with the hiring manager (45 min, video)
day 11   async written round: 4 short prompts on team scenarios, 1 hour budgeted (due day 13)

Three of the five rounds were async. The total live time was about 2 hours. The total async time was something like 8 hours of my work and probably 4 hours of theirs. The shape made sense once I understood that the company's whole operating mode was async: async interviews are a working test, not a proxy for a working test.

The written take-home (design doc, not code)

The prompt was a 1 page google doc. Anonymized:

A customer is asking for a webhook delivery system that supports retries with backoff, signed payloads, and a per-customer rate limit. We are not asking you to build it. Write a design doc for it. The doc should be the doc you would write to get this approved at our company. Aim for 4 pages or fewer. Due in 3 business days.

The instruction "the doc you would write to get this approved at our company" was the instruction that mattered. They had given me 4 sample design docs from their own engineering wiki, with the company-identifying parts redacted. The samples had a specific shape: short tldr, one section on "why this matters", one section on the design proper, one section on rejected alternatives, one section on "what could go wrong".

I wrote my doc in that shape. I spent 2 hours on it on a Saturday morning, took a break, came back for 90 minutes Sunday afternoon to revise. It came in at 3 pages. The hardest part was the rejected-alternatives section: I had to credibly engage with two alternatives I was not going to pick (a single-shared-queue model, and a strict-FIFO-per-customer model) and explain why neither was right for this prompt. The rejected-alternatives section is what most candidates skim, and the company told me later that it is the section they read first.

The Loom-video round

The round prompt: record a 12 to 18 minute Loom video walking through the design doc, then answer 4 written follow-up questions in the same submission.

The 4 questions were:

1. Which part of the design are you least confident about and why
2. What would change if we 100x'd the customer count
3. What would the on-call rotation look like for this system after launch
4. If we had 2 weeks of engineering time instead of 6, which parts would you cut

The questions were the round. They were grading whether I had actually thought through the design or whether I had written the doc to look complete. Question 1 was the trap: a confident-sounding answer would be wrong. The right answer was specific: I named the rate-limiter implementation as the part I was least confident about, gave two specific reasons (the cross-region consistency, the customer-quota update path), and described the experiment I would run to gain confidence.

The Loom video itself was the second hardest part of the loop. Recording a 14 minute video walkthrough is genuinely different from talking through a design live, because there is no interviewer to ask the right questions. I had to ask my own follow-ups and answer them. The first take I made was 22 minutes and meandering. I redid it. The second take was 15 minutes. The thing that helped was writing a 5 bullet outline before recording and sticking to it.

I submitted the video and the answers on day 7, not day 8. The 24 hours felt important; the recruiter had said no rush, but I wanted to signal that I could move at the company's actual operating speed.

The live coding round

The live coding round was the most familiar part of the loop. 45 minutes, one problem, the interviewer was on camera. The problem was a small queue-deduplication shape (given a stream of webhook events with possibly-duplicate ids, write a small store that deduplicates within a window). I solved it in 32 minutes. The follow-up was about handling the dedup store crashing and recovering: do you persist the seen-ids, do you accept double-delivery for a window, what is the contract you give the customer.

I gave the answer that matched their actual product: write the seen-ids to disk async, accept that on a crash you might double-deliver up to one batch, document the contract in the customer-facing API. The interviewer said "that is the answer; we double-deliver up to 60 seconds and tell customers to be idempotent". The round was grading whether I had read the doc samples carefully enough to know what kind of answer they wanted.

The live behavioral and the final async round

The behavioral round was 45 minutes with the hiring manager. He was based in central Europe; we did the call at his 4pm and my 9am. He spent most of the time asking me about my last team's async practices: how long async PR review threads typically took, what we did when a thread had been silent for 3 days, how we handled disagreements that did not converge async. The questions were grading whether I knew how to operate async or whether I would import sync habits and slow the team down.

The final round was an async written round: 4 short scenario prompts, 1 hour budgeted total. Each prompt was 1 to 2 sentences, like "a teammate has been silent on a thread you opened 4 days ago and you have a deadline tomorrow; what do you do". I wrote 200 words per answer, sent them on day 12.

What the loop was actually grading, distilled

Three things, in order:

First, can you produce written work that lands the same signal a 45 minute live conversation would. The take-home and the Loom video were grading exactly this.

Second, can you pace the loop on the company's calendar without me telling you. Submitting the Loom on day 7 instead of day 8 was a signal. Submitting on day 9 would also have been fine. Submitting on day 8 right at the deadline would have been a softer signal.

Third, do you have async habits or do you have sync habits. The behavioral round and the final async round were both calibrated on this. Sync habits include things like "I jump on a call to unblock", "I follow up in slack until I get a response", "I prefer to talk it out". Async habits include "I write a doc that pre-empts the call", "I tag the right person and then move on", "I propose a decision in writing and let the team push back async". Neither is wrong; the loop was grading whether I had the second set or could credibly claim I would build them.

The outline-before-recording rule I learned the hard way

I got the offer and accepted. The role has been the right fit. The thing I would do differently next time is the Loom video. The first take was 22 minutes because I tried to cover everything; the second take was 15 minutes because I had a 5 bullet outline. If I were doing it again I would write the outline first thing, before any recording. The video format rewards structure more aggressively than the live conversation format does, because there is no interviewer to redirect me when I drift.