Running 17 interview processes in one month

On April 15, 2026, I had three interviews in one afternoon: 12:30, 3:00 and 4:00. The first was for a recommendation systems role at a small startup, the second for a generative AI role at a fintech, the third for a data science role at a B2B AI company. Each had a different interviewer, a different definition of what “senior” meant, and a different set of things I had prepared that morning. Between the second and the third I had a few minutes to switch from LLM evaluation to two-tower retrieval models.

That afternoon was the peak of the busiest month in my job search. In April I had live processes with 17 companies and sat 24 interview rounds. In one week, three take-home assignments were in flight at the same time.

This post describes the operating model that made that month workable: a brief for every company, a shared preparation core instead of per-company cramming, a calendar treated as the source of truth, and an explicit keep-or-drop gate after every round. It is part 4 of the 35 companies, 8 offers series, and it is mostly about logistics, because logistics is what fails first when you run many processes at once.

The month in numbers:

• Companies with activity in April: 17
• Live interview rounds: 24, including 7 in the single week of April 13–17
• Take-home assignments: 3 in flight in the same week
• Outcomes of the April processes: 5 eventual offers, 1 rejection, 11 processes I stopped
• First offer: April 11, which changed every decision after it

Background: why run them in parallel at all#

Running many processes at once is not an accident of a busy month. It is a deliberate strategy, and it has real costs.

Offers create leverage and momentum. Haseeb Qureshi’s widely read rules for negotiating a job offer argue that the goal should be to have as many offers overlapping at the same time as possible, and that the number and strength of offers is the single strongest determinant of the final outcome. Sequential processes give you one offer at a time and no comparison.

Fast and slow processes need to overlap. Startups move in days; large companies move in weeks or months. The same guide recommends starting with the slower ones early. My Google process began with a recruiter call in late March and did not produce an interview date until the end of May. Everything else in this post happened inside that wait.

The costs are real. Every switch between processes costs something. In laboratory experiments, Rubinstein, Meyer and Evans found that people lose time on every switch between tasks, and that the cost grows as the tasks become more complex and less familiar. Switching between three interview domains in an afternoon is that cost at its most expensive.

Running many processes only works if you are willing to drop most of them. Without a drop rule, parallel processes turn into shallow preparation for everything.

The operating model#

Every process followed the same lifecycle, and every stage had one artifact or one decision attached to it.

graph LR
    A["Recruiter call<br/>or application"] --> B["Qualify:<br/>role, level, fit"]
    B -->|"no"| X["Decline early"]
    B -->|"yes"| C["Company brief"]
    C --> D["Round"]
    D --> E["Same-day debrief"]
    E --> F{"Keep or drop"}
    F -->|"keep"| C
    F -->|"drop"| Y["Withdraw politely"]
    F -->|"offer"| Z["Evaluate offer"]

    class A,B gray
    class C,D,E amber
    class F violet
    class X,Y red
    class Z green

The model has two properties that mattered more than any single stage. Every process was always in a known state, so I never had to remember where something stood. And every round ended in a decision, so nothing drifted along on momentum because I was too busy to end it.

The company brief#

Before the first round with any company, I wrote a brief with Claude covering three things: the company (what it sells, its stage, its likely ML problems), the role (what the job description emphasized and what it left out), and, where I could find it, the interviewer’s background.

The interviewer section changed my preparation more than anything else. An interviewer who came from backend and full-stack engineering would probe production architecture, APIs and failure handling, not modelling theory. An interviewer whose background was in quantitative research and contextual bandits would probe probability, statistics and experimental design. The same role at two companies could need almost opposite preparation depending on who was asking.

The briefs also taught me something about depth. My early briefs were either too shallow (a page of company facts) or too deep (twenty pages of theory nobody would ask about). The version that worked was short and opinionated: likely question areas ranked by probability, the two or three stories from my work that mapped best to the role, and the specific concepts to refresh that morning.

A shared core instead of per-company cramming#

With 17 companies, preparing from scratch for each one was impossible. The answer was a shared core of preparation that every brief pointed into, with a thin company-specific layer on top.

graph TD
    A[("Story bank")] --> E["Company brief"]
    B[("Metric bank")] --> E
    C[("ML theory docs")] --> E
    D[("Design templates")] --> E
    E --> F["Company A round"]
    E --> G["Company B round"]
    E --> H["Company C round"]
    F --> I["Debrief patches<br/>the shared core"]
    G --> I
    H --> I
    I --> A
    I --> C

    class A,B,C,D blue
    class E amber
    class F,G,H violet
    class I green

The story bank held my strongest work stories with their numbers, each one tagged by the kinds of question it answered. The metric bank held every number on my resume with its definition and its system. The theory documents covered ML fundamentals at interview depth. The design templates started every design answer with entities and data before models.

The theory documents are the best example of how this compounded. Preparing for one ranking role whose first round covered linear algebra, probability and statistics produced a five-part set of documents: optimization and regularization, backpropagation and losses, linear algebra through PCA and SVD, probability with maximum likelihood and maximum a posteriori estimation, and distributions with A/B testing. I wrote them to be general rather than company-specific. They served that one round, every ML round after it, and eventually the Google ML domain round three months later.

The rule I settled on: if a piece of preparation would only ever help with one company, keep it in the brief and keep it short. If it would help with two or more, it belongs in the core.

The calendar as the source of truth#

Every round, reschedule, take-home deadline and follow-up lived in one calendar. When I later reconstructed the search for this series, that calendar was the only reason I could date most of it.

Three scheduling lessons came out of April.

Cluster by domain, not by convenience. Three interviews in one afternoon was survivable. Three interviews in three different domains in one afternoon was not ideal. When I had control over slots, I tried to put similar roles on the same day so the morning’s preparation served all of them.

Reschedule early and briefly. I rescheduled two interviews around this period, once for illness and once for an appointment I could not move. Both times the email was short: the reason in one line, an apology, and a window of availability starting the next day. The second one moved a Tuesday interview to Thursday of the same week. Recruiters reschedule often; the only bad reschedule is a late one.

Take-homes need blocks, not gaps. Three take-home assignments were in flight in the same week in early April. A take-home cannot be done in the hour between two calls. I blocked whole half-days for each and moved everything else around them. The take-home post in this series covers how I built them.

Keep or drop: the decision after every round#

The most important habit of the month was ending processes. After every round I answered three questions:

1. Does the role match what was advertised?
2. Would I take this offer today if it arrived?
3. Is the next round worth the preparation it will cost?

A “no” to any of them ended the process. Of the 17 companies active in April, I stopped 11, most of them after a single round. That sounds wasteful until you compare it with the alternative: preparing seriously for 17 second rounds at once.

The first offer, on April 11, changed the calculus. Once I had an offer in hand, the bar for question 2 went up: a process now had to beat a real offer rather than an imaginary one.

Withdraw early and briefly. My withdrawal emails said that I was progressing with another opportunity and wanted to be respectful of the team’s time, without naming anyone or giving reasons. Nobody ever asked for more.

Decline offers like a person. My first draft of an offer decline read like a template, and I rewrote it to sound like something a real person would type: an acknowledgment that I had taken a while to reply, a line about not wanting to keep them waiting, and thanks that I meant. The people on the other side of a decline are people you may meet again.

Results#

The outcomes of the 17 processes active in April:

The month produced five of my eight eventual offers. It also produced most of the material the rest of the search ran on: the story bank, the metric bank, the theory documents and the design templates were all built or rebuilt in April, then reused through August.

The cost was visible too. Some rounds in the peak week got preparation measured in minutes rather than hours, and a few debriefs from that week show it: answers that were correct but unstructured, and metrics swapped under pressure.

What I’d do differently#

Cap live processes at about eight. Seventeen was more than I could prepare for properly. Most of the eleven processes I stopped could have been filtered out at the recruiter call with sharper questions about level, scope and team.

Qualify harder before the first round. The first round is the most expensive part of a process, because it needs a fresh brief. Spending ten more minutes on the recruiter call to check level, team and the actual problem would have saved several first rounds.

Never stack different domains on one day. Same-domain clusters are efficient. Mixed-domain afternoons look efficient on the calendar and are not.

Ask for time on every offer. The negotiation guide above recommends that the first thing to ask for after an offer is time. I learned to do that later in the search than I should have.

Conclusion#

Running many processes in parallel is a leverage strategy with a cost, and the cost is attention. The model that made it work was not clever: every process in a known state, a short brief per company on top of a shared core, one calendar, and a decision after every round. The decision is the part most people skip, and it is the part that makes the rest possible.

Keep processes alive only while they can still beat your best alternative. Everything else is preparation you are taking away from the ones that can.

Part 4 of the 35 companies, 8 offers series. I join Google as a Software Engineer III, AI/ML, in October 2026.