Company loop formats

What it is

Loops differ less in what they ask than in what they weight, and the weighting is a consequence of what each company has decided its failure mode is. Knowing the shape tells you where to spend preparation time, which is the only actionable thing about it.

A warning that belongs at the top rather than in a footnote: formats change, often within a year, and the only current source is your recruiter. Everything below is the shape as publicly reported and as commonly described by candidates. Ask the recruiter for the round list and the rubric before you plan anything, and treat what follows as a prior to be updated rather than a schedule.

The durable question, per company, is not "how many rounds"
but:

  what does this company believe goes wrong when they hire
  badly, and which round is the one that exists to catch it?

What this is confused with: loop trivia as preparation. Knowing that a company runs two coding rounds does not help. Knowing that its coding rounds are two problems in forty-five minutes, so speed rather than depth is the failure mode, changes what you practise.

Also confused: the loop and the bar. Two companies with identical formats can have very different bars, and the format tells you what to prepare rather than how hard it will be.

The problem it solves

Preparation time is finite and defaults to whatever you are already comfortable with.

A candidate with 60 hours of preparation, spread evenly:
  20h algorithms
  20h system design
  20h behavioural

Against a loop that is 10 to 16 leadership-principle
questions plus a bar raiser, this allocation is wrong by a
factor of about three on the axis that decides the outcome.

Against a loop that is two problems per 45-minute coding
round, the 20 hours of algorithms were spent on depth when
the failure mode is speed.

Same 60 hours. The allocation is the whole decision, and it
should be made from the loop rather than from habit.

And the second failure: preparing for a format that does not exist there.

Drilling distributed-systems design for a loop whose design
round is a product-shaped question about a matching system
with geographic constraints. Both are "system design" and
they reward different preparation.

Mechanics

The shapes, and what each is defending against

These are reported shapes, not guarantees. Verify with the recruiter.

GOOGLE (staff / L6, TLM)
  Reported shape: two coding rounds, one or two system
  design, one leadership-and-"Googleyness".
  WHAT IT DEFENDS AGAINST: hiring someone whose scope cannot
  be written down. A hiring committee reads a packet and was
  not in the room, so your interviewers must be able to
  RECORD your scope in a sentence.
  Consequence for you: give quotable lines. "Owned the event
  schema across four teams" survives transcription; a good
  impression does not.
  Design rounds reported to go deep on data modelling and
  failure handling.
  Rough weighting: coding 30, design 40, leadership 30.

META (E6, engineering manager)
  Reported shape, IC: two coding rounds with TWO PROBLEMS
  EACH in 45 minutes, one system design, one behavioural.
  EM: system design, people management, a project
  retrospective, sometimes coding.
  WHAT IT DEFENDS AGAINST: slowness. The two-problems-in-45
  format is the format, and candidates fail it on pace
  rather than on ability.
  Consequence: practise the pace explicitly, timed, two
  problems, not one hard problem slowly.
  E6 requires org-level impact: "I built X" reads as E5,
  "I changed how three teams do X" reads as E6.

AMAZON (principal / L7, SDM)
  Reported shape: leadership principles dominate, 10 to 16
  LP questions across the loop, plus a Bar Raiser, plus
  system design and for senior levels a technical-vision
  discussion.
  WHAT IT DEFENDS AGAINST: a hiring manager lowering the bar
  under headcount pressure, which is what the Bar Raiser
  exists for, and unsubstantiated claims, which is what
  "Dive Deep" enforces.
  Consequence: two stories per principle, sixteen
  principles, and EVERY answer carries data. "Dive Deep"
  means they will ask for the number three layers down, and
  "we improved latency significantly" fails.
  This is the most story-intensive loop in the industry and
  it is the one where preparation volume most directly
  converts into outcome.

STRIPE
  Reported shape: an integration round building against a
  real API, a debugging round fixing a broken repository,
  system design, and a values round.
  WHAT IT DEFENDS AGAINST: candidates who can whiteboard and
  cannot ship. Practical over algorithmic.
  Consequence: your editor fluency, your debugging method
  and your comfort in an unfamiliar codebase are all
  visible. Rough weighting: debugging and pragmatic coding
  50.

NETFLIX (senior / staff)
  Reported shape: deep technical conversation, culture-memo
  alignment as a genuine filter, and an expectation that you
  justify autonomy.
  WHAT IT DEFENDS AGAINST: someone who needs process. The
  culture is context-not-control and the keeper test, and a
  candidate who describes their success in terms of the
  process around them reads as a poor fit.
  Consequence: prepare to describe decisions you made
  without asking, and be able to discuss the culture memo
  substantively rather than reciting it.
  Rough weighting: deep dive 40, culture 30, design 30.

DATABRICKS / SNOWFLAKE / CONFLUENT
  Reported shape: hard distributed-systems internals plus
  genuinely hard coding.
  WHAT IT DEFENDS AGAINST: shallow familiarity. Expect query
  execution, storage formats, consistency models and
  concurrency at a level where "eventually consistent" as a
  phrase is not an answer.
  Consequence: storage and streaming internals are roughly
  half the preparation.

UBER / LYFT / DOORDASH
  Reported shape: high-scale system design with real domain
  constraints, geo, matching, dispatch, pricing; coding
  medium-hard.
  WHAT IT DEFENDS AGAINST: generic design answers. The
  design round is the differentiator and it has domain
  physics in it: a matching system has a spatial index, a
  supply-demand imbalance, and an interference problem that
  a generic "put a queue in front of it" answer does not
  touch.

SHOPIFY (Toronto)
  Reported shape: a "Life Story" interview walking through
  your career, pair programming in a real repository, and a
  technical deep dive.
  WHAT IT DEFENDS AGAINST: a rehearsed highlight reel. The
  life-story format wants a narrative arc with reasons, not
  a list of jobs.
  Consequence: prepare the arc, including the transitions
  and why you made them. Pair programming in a real repo
  means the same unfamiliar-codebase skill Stripe tests.

OPENAI / ANTHROPIC / AI LABS
  Reported shape: practical coding, often agentic, working
  in a real codebase with real tools; a take-home with a
  follow-up deep dive; strong emphasis on judgment and
  safety-mindedness.
  WHAT IT DEFENDS AGAINST: people who cannot move in
  unfamiliar code, and people with no considered position on
  risk.
  Consequence: practise contributing a real fix to an
  open-source repository you have never seen, timed. And
  have a considered, non-performative view on where the
  systems you build can cause harm.

NVIDIA / CISCO / SYSTEMS COMPANIES
  Reported shape: performance, concurrency, memory,
  profiling; C++ and systems questions where the role is
  close to the metal.

Turning a shape into an allocation

Ask the recruiter, in one message:
  - the round list, with durations
  - whether coding is one problem or two per round
  - whether the design round is distributed-systems or
    product/domain shaped
  - whether there is a take-home, a debugging round, or a
    pairing round
  - who the bar-raising or committee function is, if any
  - the level being interviewed for, and the band

Most recruiters answer all of it. The information changes
your allocation more than any amount of general study.

Then allocate:
  the round most likely to fail you   40%
  the round with the most weight      30%
  everything else                     30%

Those are often different rounds, which is the point of
asking.

The universal preparation, which is most of it

Whatever the shape:

  4 to 6 STORIES that each carry three or four of the six
    signals, tellable in three minutes.
  ONE DEEP DIVE, 45 minutes, at three zoom levels, with
    numbers, alternatives and regrets.
  DESIGN FLUENCY: capacity arithmetic out loud, three
    consistency models and when each is acceptable, a
    multi-region write path, a migration and rollback plan.
  CODING at the pace the loop requires, which you established
    by asking.
  THE QUESTIONS you will ask, per interviewer.

That set covers 80% of every loop above. The company-specific
work is the last 20% and it is an allocation decision rather
than new material.

A worked example: the same candidate, three loops

A senior engineer targeting staff, interviewing at three companies over four months, with roughly the same 50 hours of preparation available before each.

Loop 1, a large consumer company, prepared by habit:

Allocation: 20h algorithms, 20h system design, 10h stories.

The loop, as it turned out: two coding rounds at two
problems per 45 minutes, one design, one behavioural.

Result: failed both coding rounds on pace. Solved the first
problem in each round well and ran out of time on the
second.

The candidate's post-mortem: "I'd practised hard problems
slowly. The round is medium problems fast, and those are
different skills. I never asked."

Loop 2, a company with a principle-based loop, prepared after asking:

Recruiter's answer to one email: fourteen leadership-
principle questions across five rounds, a bar raiser, one
system design.

Reallocation: 35h stories, 10h design, 5h coding.

Preparation specifics:
  - two stories per principle, sixteen principles, which is
    thirty-two story slots filled by about eleven underlying
    projects told from different angles
  - every story rebuilt to carry a NUMBER, because "dive
    deep" means the follow-up asks for the metric three
    layers down
  - practised the follow-up chain out loud: "how much did it
    improve" -> "how did you measure that" -> "what was the
    baseline" -> "who else could confirm that number"

Result: offer.

The candidate's note: "the third and fourth follow-up is
where people fall apart. I'd never rehearsed past the second."

Loop 3, a practical-shaped loop, prepared after asking:

Recruiter's answer: an integration round against a real API,
a debugging round on a broken repository, one design, one
values round.

Reallocation: 20h unfamiliar-codebase practice, 15h design,
10h stories, 5h API integration.

The unfamiliar-codebase practice, which was the new thing:
  cloned four open-source repositories, had a friend
  introduce a bug in each, fixed them timed, narrating the
  hypothesis-and-disproof loop out loud.

Result: offer, and the debugging round was the strongest
score in the loop.

The candidate's note: "I've debugged for eleven years and
had never done it out loud in someone else's code with a
clock running. Four practice runs was the difference."

Across three loops with the same total preparation time, two offers and one failure, and the failure was the one where the allocation was made from habit rather than from the format.

What the one email was worth:

Time to write the recruiter email:        ~5 minutes
Time to read the answer:                  ~2 minutes
Change in allocation it produced:         substantial in
                                          both cases
Cost of not sending it in loop 1:         the loop

There is no preparation activity with a better ratio, and
almost nobody does it.

Production evidence

Amazon's Leadership Principles and Bar Raiser program are publicly documented by Amazon, including the Bar Raiser's authority to block a hire independently of the hiring team, which is the mechanism behind the loop's story intensity and its data requirement.

Google's hiring committee model, where a packet is assembled and reviewed by people who did not conduct the interviews, is publicly described and is the direct reason interviewers must be able to write down a candidate's scope in a transcribable sentence.

Netflix's culture memo is published and is explicitly used as a filter; its "context not control" and keeper-test framing are the substance a Netflix loop expects a candidate to engage with rather than recite.

Stripe's engineering blog and its published interview guidance describe an integration round and a debugging round against real code, with a stated preference for practical over algorithmic assessment.

Shopify's "Life Story" interview is publicly described in its own hiring materials as a structured walk through a candidate's career rather than a competency grid.

AI labs' emphasis on agentic and unfamiliar-codebase work is visible in their published role descriptions and in candidate reports, and it follows directly from the work: the job involves moving quickly in large codebases with tooling assistance.

All of the above shift. Public reporting lags by months to years, which is why the recruiter is the only current source and why this page's most important content is the instruction to ask.

The debate

Is it worth learning company-specific formats? Worth asking about, not worth memorising. The company-specific work is roughly the last twenty percent of preparation and it is an allocation decision rather than new material, and the eighty percent, stories, a deep dive, design fluency, coding at the required pace, is shared.

Is Amazon's loop excessive? It is the most story-intensive in the industry and it is also the most predictable, which cuts both ways. The volume is genuinely large, and the return on preparation is higher there than anywhere else because the rubric is published and the format is stable. The critique that lands is that it rewards preparation time, which is not evenly available.

Do two-problems-per-round formats measure the right thing? They measure speed on medium problems, which is a real and narrow skill. The defence is that it correlates with fluency; the objection is that it selects against people who think before typing, which is a disposition many good engineers have. Either way it is the format, and losing to it while being capable of the problems is a preparation failure rather than an ability one.

Are practical loops (Stripe, Shopify, AI labs) better? They resemble the job more closely and they are harder to prepare for by drilling, which is arguably the point. The asymmetry is that a candidate who has never worked in an unfamiliar codebase under time will underperform their ability, and four timed practice runs closes most of that gap.

Should you tailor stories per company? The framing yes, the facts no. The same project told against Amazon's principles, Meta's org-impact bar and Netflix's autonomy expectation emphasises different clauses, and inventing content to fit is both dishonest and detectable, because the follow-up chain goes three or four questions deep.

Is the recruiter a reliable source? For format and level, yes, and they are usually willing. For difficulty and for what the specific interviewer will ask, no. The failure is not asking at all, which in one case cost a loop that the candidate was technically capable of passing.

Follow-up Q&A

"How do you prepare for a loop whose format you do not know?"

Ask the recruiter, in one email: the round list with durations, whether coding is one problem or two per round, whether the design round is distributed-systems or product-shaped, whether there is a take-home, debugging or pairing round, whether there is a bar-raising or committee function, and the level and band. Most recruiters answer all of it. Then allocate roughly 40 percent to the round most likely to fail you, 30 to the round with the most weight, and 30 to everything else, which are frequently different rounds. Five minutes of email changes the allocation more than any amount of general study.

"What is the durable question about a company's loop?"

Not how many rounds, but what that company believes goes wrong when they hire badly and which round exists to catch it. Amazon's Bar Raiser defends against a hiring manager lowering the bar under headcount pressure. Google's committee model defends against a hire whose scope nobody can write down, which is why quotable lines matter more than a good impression. A two-problems-per-45-minutes coding round defends against slowness. Stripe's debugging round defends against candidates who can whiteboard and cannot ship. Each implies a different preparation.

"What is specific about preparing for a principle-based loop?"

Volume and data. Two stories per principle across sixteen principles is thirty-two slots, usually filled by about a dozen underlying projects told from different angles. Every story must carry a number, because "dive deep" means the follow-up asks for the metric three layers down. And rehearse the follow-up chain past the second question: how much did it improve, how did you measure it, what was the baseline, who else could confirm that number. In one loop the candidate's note was that the third and fourth follow-up is where people fall apart and they had never rehearsed that far.

"How do you prepare for a debugging or pairing round in an unfamiliar codebase?"

By practising in an unfamiliar codebase, which most people never do because they debug their own code daily and assume it transfers. Clone four open-source repositories you have never seen, have someone introduce a bug in each, and fix them timed while narrating the hypothesis-and-disproof loop out loud. In one case four practice runs turned a format the candidate had never performed into the strongest score in their loop, after eleven years of debugging professionally without ever doing it out loud with a clock running.

"Should you tell different stories at different companies?"

Same stories, different emphasis. The same migration told against Amazon's principles foregrounds the data and the dive-deep detail; told against Meta's E6 bar it foregrounds how three teams changed; told at Netflix it foregrounds the decisions you made without asking permission. Inventing content to fit is both dishonest and detectable, because the follow-up chain goes three or four questions deep and fabricated detail does not survive it.

"How current is any published information about loops?"

Not current enough to rely on. Formats change within a year, public reporting lags by months to years, and the only reliable source is the recruiter for that role at that moment. Treat any written description, including this one, as a prior to be updated by one email rather than as a schedule, and note that this also applies to advice from a friend who interviewed there eighteen months ago.

Common misconceptions

"Knowing the round count is preparation." It is trivia. Knowing that the coding round is two problems in forty-five minutes, so pace rather than depth is the failure mode, changes what you practise.

"System design is system design." A distributed-systems design round and a domain-shaped design round about matching or dispatch reward different preparation, and both are called system design.

"The behavioural round is the easy one." At a principle-based loop it is ten to sixteen questions with a data requirement and a follow-up chain three or four questions deep, and it is where the loop is decided.

"I debug every day, so a debugging round is free." You debug your own code. The round is unfamiliar code, under time, narrated, which is a different performance.

"Published loop descriptions are accurate." They lag by months to years, and formats change. The recruiter is the only current source.

"Preparation time is fungible." Sixty hours allocated by habit against a loop whose failure mode you did not ask about is the most common way a capable candidate fails.

Interview delivery note

There is no line to deliver here; the deliverable is the email. Send the recruiter one message asking for the round list with durations, whether coding is one problem or two per round, whether the design round is distributed-systems or domain-shaped, whether there is a take-home or debugging round, and the level and band. It takes five minutes, most recruiters answer all of it, and it changes your allocation more than any other single activity.

The senior-versus-staff separator is allocating preparation from the format rather than from habit. A senior candidate studies what they enjoy studying. A staff candidate asks what the loop is, identifies which round is most likely to fail them (which is usually not the one with the most weight), and puts forty percent of the time there. In one case the same fifty hours produced a failure and then two offers, and the only difference was that the allocation for the second and third loops was made from the recruiter's answer.

The second signal is treating every published description, including this page, as a prior. Saying "the shape as reported is X, and I asked the recruiter and it is now Y" demonstrates the same disposition as re-measuring a number in a DR document rather than trusting the one written two years ago.

The Staff & Team Lead Interview Reference