Six months after the Series A loop I wrote about elsewhere, I ran a Series C loop at a hyper-growth company (about 250 engineers when I joined, doubled in the year before, B2B vertical SaaS, San Francisco-headquartered with a remote-friendly NYC pod). The loop took 12 days from first call to offer, the technical bar was high, and the calibration was completely different from both the FAANG loops and the Series A loop. The Series A wanted to know if I would be a good engineer in their codebase in two years. This Series C wanted to know if I would ship something useful in the next two weeks.

The 12-day Series C shape

Four rounds, scheduled tight:

• Day 1: 30 minute recruiter call (logistics + comp band confirmation)
• Day 4: 60 minute coding round (a senior engineer, real problem from the codebase, paired in their tooling)
• Day 7: 60 minute system design round
• Day 10: 90 minute split round, 45 minutes with the hiring manager and 45 minutes with the VP of engineering, back to back
• Day 12: offer

The recruiter said up front: "we hire fast and we lose the candidates we like to slower companies if we drag the loop out". That was the whole calibration of the loop in one sentence. Speed mattered to them, and they were grading whether I would be the same way once I was inside.

The coding round was a real PR

The interviewer pasted me a link to a sandbox version of their codebase (read-only fork, branched a week earlier) and said "there is a flaky integration test in tests/billing/test_invoice_generation.py. Make it not flaky. You have 50 minutes".

This is genuinely how their engineers spent their week. The flake was in a test that involved a fake clock and a per-tenant timezone. The clock was being advanced at test setup but the tenant timezone was being read at test runtime, so any tenant configured for a non-UTC timezone got an off-by-one whenever the test ran near a DST boundary or near midnight UTC.

I spent 12 minutes reading enough of the codebase to figure out what freeze_time was doing, 18 minutes narrowing the bug, 10 minutes writing a fix that monkeypatched the timezone resolution to use the frozen clock, and 10 minutes writing a test for the fix that would have failed before. The interviewer kept his camera on but his lips were moving the whole time, like he was scoring out loud. At minute 50 he said "that is the right shape of fix; the cleaner version is to thread the clock through the timezone resolver instead of monkeypatching, but you found the bug in 30 minutes which is faster than half our team would".

The round was not grading whether I could solve a problem I had not seen. It was grading how fast I could orient inside a codebase I had not seen, and whether my instinct under time pressure was to read enough or to start typing.

The system design round was about migration, not greenfield

The prompt: "we currently store invoice line items in a single Postgres table that is now 800 million rows. Reads are getting slow. Walk me through what you would do".

This was not a system design round in the FAANG sense. There was no greenfield. There was an actual table, an actual query pattern (90% of queries were a WHERE tenant_id = ? AND invoice_id = ? join), and an actual constraint (we cannot take a 4-hour write lock to migrate). The interviewer wanted to see whether I would over-engineer or under-engineer.

I walked through the obvious sequence:

phase 1, this sprint:
  add a covering index on (tenant_id, invoice_id, created_at) if not present
  measure read latency before and after
  cost: 1 engineer-day, zero customer-visible risk

phase 2, next sprint if phase 1 not enough:
  partition the table by tenant_id range
  use pg_partman or hand-rolled partitions
  cutover one tenant at a time, behind a feature flag
  cost: 1 engineer-week, low customer-visible risk

phase 3, only if phase 1 and 2 not enough:
  shard out tenant by tenant onto separate Postgres instances
  introduce a routing layer
  cost: 1 engineer-quarter, real customer-visible risk

The interviewer pushed me on phase 1: "are you sure you do not want to skip to phase 2". I said no, because phase 1 had a 1-day cost and a 70% chance of being enough. He nodded and moved on. He told me later in the loop that most candidates jumped straight to sharding, and that the team had been burned by a candidate who joined and proposed a 2-quarter migration in his first month.

The round was grading sequencing under operational constraints. The thing they did not want was someone who had read "Designing Data-Intensive Applications" once and wanted to apply every chapter on day one.

The 90 minute split round

First 45 minutes with the hiring manager, who was the engineering manager I would report to. He had read my coding round writeup. He opened with "the engineer who interviewed you on Friday said you found the bug in 30 minutes. Tell me what you would have done if you had 4 hours instead". I told him: I would have written the deeper fix (thread the clock through the timezone resolver), I would have audited the rest of the test suite for the same pattern, and I would have written a one-page doc on it for the team. He said "that is what we want, but on the second hour, after you ship the 30 minute fix". This was the calibration: ship the small fix first, then deepen, do not block on the perfect fix. I have heard senior engineers at slower companies say the opposite of this and mean it. Both can be right; what matters is matching the company you are joining.

The second 45 minutes were with the VP of engineering. He spent 10 minutes asking about my last team and 35 minutes asking what I would change about their engineering org based on what I had seen in the loop. I had three observations. The third one was wrong (I thought their on-call rotation was thin; it turned out they had recently restructured it and what I had seen was the old shape) and he corrected me. The first two he agreed with and asked follow-ups on. He told me the offer would come within 48 hours. It came in 36.

Speed over polish, what that actually meant

Later, after I joined, I asked the VP what they had been grading. He said three things: "can you orient fast, can you ship something useful before the perfect thing, will you tell me you were wrong instead of defending it". The first one was the coding round, the second one was the system design round, the third one was the split round. They were not grading polish. They were grading whether I would do the small useful thing on Tuesday instead of the perfect thing in October.

The 90-second habit I would walk into the next hyper-growth loop with

I took the offer and stayed 22 months, which is forever in hyper-growth time. The single thing I would do differently if I ran this loop again is the system design round. I should have anchored phase 1 in numbers. I had said "70% chance of being enough" out loud, but I should have justified it: the access pattern is point-lookup, the slow path is most likely an index scan, and the indexes I proposed cover it. If I had walked through that math out loud, I would not have needed the interviewer to push back on me. The pushback meant I had asserted a number without showing my work. That is the kind of thing you can fix in 90 seconds of habit, and if I had been doing it in this round, I would have set the bar higher in the next one.