How Google interviews — Question to Offer

1. The shape of a Google loop

Google runs the most committee-driven hiring process at scale. The interviewers are not the deciders. The hiring committee is. Your job during the loop is to leave behind clean, easy-to-write rubric signals that the committee can read without having met you.

A standard onsite is four to five rounds for L4/L5, five to six for L6+. Each round is 45 minutes. Two are coding, one or two are system design, one is what Google calls general cognitive (Googleyness + leadership, behavioral-flavored, often with a small coding or design element), and one is a cross-functional slot — a senior IC from a different team than the hiring one, whose role is to keep the bar uniform across the company.

The cross-functional interviewer is the closest thing Google has to a bar raiser. They have no incentive to like you. Their job is to write a rubric the committee believes.

2. What Google grades you on

Four signals, by their own framework: General Cognitive Ability, Role-Related Knowledge, Leadership, Googleyness. In a system design round, the first two carry almost all the weight. Leadership shows up in how you frame ownership. Googleyness mostly translates to can two senior engineers stand to work with this person for years?

For system design specifically, Google leans heavier than most companies on platform-shaped problems: web-scale storage, planet-scale crawling, real-time collaboration on a massive shared object, ad serving at billions of QPS. The implicit constraint on every answer is what happens at Google scale. If you scope a design for 1M users without acknowledging the company runs systems at 1B+, you signal that you don't know what room you're in.

3. What's different here

The interviewer is not your decider. Write the rubric for the committee. That means: leave behind the signal explicitly. Restate the requirements out loud at minute 14 ("so to recap, we've decided X, Y, Z") so the interviewer can write down a clean rubric line.
Depth on a single seam outscores breadth. Google interviewers will often let you choose your depth seam, then push three times. If you survive three rounds of yes-but-what-if, you score depth at level. If you stay on the seam too long and miss tradeoff, you score depth-at-level but lose tradeoff. The clock is unforgiving here.
Scale is the default constraint. "How would this work if you had a thousand times the traffic?" is asked, eventually, in every round. Have an answer ready before they ask.
Distributed systems literacy is expected. Consistent hashing, leader election, quorum reads, Paxos at a sentence level, the failure modes of replication. You don't need to derive Paxos. You need to use the vocabulary correctly.
Google has shipped most of the canonical papers in this space. Bigtable, MapReduce, Spanner, Chubby, Borg. Knowing the shape of those systems and what they were designed to solve is a Google-specific advantage. Mention one by name correctly and the interviewer warms up.

4. The level bar

How the bar shifts:

L3 / L4 (entry / junior senior) — design at the competent IC level. Scope is graded. Estimation is graded. The diagram is the main artifact. Depth is shallow; a single seam, named correctly, is enough.
L5 (senior) — design at the platform-aware level. Depth is graded. You need at least one deep dive that survives three pushes. Tradeoff sentences expected on every major choice.
L6 (staff) — design at the systems thinker level. The full tradeoff sentence (from [[tradeoffs-as-the-answer]]) is expected for every major choice. Anti-patterns named. Failure modes structured. Migration plans articulated when relevant.
L7+ (senior staff / principal) — design at the organization level. The system fits inside an org that ships it. You talk about how teams own slices, how the platform evolves, how you'd run the launch and what you'd watch.

In this course, Ch 1 units target L5 by default, with explicit notes on what shifts at L6.

5. The Google-flavored mistakes

Watch for:

Underestimating scale. Designing a feed for 10M users when the question is implicitly about 1B+. The interviewer expects you to assume the larger number unless told otherwise.
Reaching for the wrong primitive. Postgres on questions where Bigtable / Spanner is the right answer. Google interviewers expect you to reach for the primitives Google has shipped papers about, even by their generic names (wide-column store, global SQL, distributed lock service).
Skipping the failure model. "What if the leader dies?" is asked on every distributed design. "What if a region goes dark?" is asked on every cross-region design. Have answers ready.
Talking the diagram without writing on it. Google interviewers (especially remote) follow what's on the board. If it's not written, the committee won't see it.
Solo-driving past the interviewer. Google interviewers expect you to check in. "Want me to keep going on this seam, or pivot?" is a senior tell here.

6. The seven scenarios in this chapter

Each unit dissects one question end to end. The chapter covers:

1.1 Web crawler at planet scale — politeness, URL frontier, dedup, recrawl strategy. The classic Google question.
1.2 Google Docs real-time collaboration — OT vs CRDT, presence, save model. Often asked at L5.
1.3 Google Drive multi-device sync — file versioning, conflict resolution, offline-first semantics.
1.4 Google Maps tile serving and route planning — geo-indexing, pre-computation, routing graph. Frequently L6.
1.5 Bigtable row locality and tablet splits — the platform-shaped question. Distinguishes systems-fluent candidates.
1.6 Distributed counter for ad impressions — idempotency at extreme write throughput, the question Stripe also asks but at lower scale.
1.7 Take-home: key-value store that survives a node loss — code task. Build, test, ship.

7. The next page

The first scenario: a web crawler at planet scale. The most-asked Google system-design question of the last fifteen years.