System design guide
The Google system design interview: format, focus and prep
Google's system design round is known for open-ended prompts and interviewers who keep changing the constraints. Here's what candidates report about the format at each level, what seems to matter, and how to prepare.
Google doesn't publish its design rubric. This page summarises public candidate reports and prep-site write-ups (sources at the end). Formats change and vary by team; your recruiter is the authoritative source.
Format by level
| Level | What candidates report |
|---|---|
| L3 (entry) | Usually no dedicated design round |
| L4 (mid) | Mixed reports: none, a lighter design discussion, or a design round depending on team |
| L5 (senior) | One standalone system design round, roughly 45–60 minutes |
| L6+ (staff and above) | Often two design rounds, with more weight on scope, trade-offs, and long-term evolution |
Design performance is also one of the main inputs for level decisions, so a strong design round can matter as much as passing it.
What the round feels like
- Vague prompts. You'll often get a one-line problem and be expected to scope it yourself. Interviewers watch how you turn ambiguity into concrete requirements.
- Moving constraints. Interviewers commonly add requirements midway ("now make it work across regions", "now the write rate is 10× higher"). That's normal, not a sign you're failing.
- Depth on fundamentals. Expect to reason about storage layouts, replication, consistency, and failure behaviour from first principles rather than by naming managed services.
- Generic or infrastructure-flavoured problems. Candidates report prompts like a web crawler, a distributed cache or key-value store, a rate limiter, a notification system, or an LLM-serving system; more product-like prompts appear too.
What seems to separate strong answers
- Explicit scoping: written requirements and stated assumptions in the first few minutes.
- Estimates that drive decisions: numbers used to justify sharding, caching, or batching. See back-of-the-envelope estimation.
- One or two real deep dives: an algorithm or data structure explained properly (e.g. the URL frontier in a web crawler, or consistent hashing in a distributed cache).
- Consistency and failure reasoning: what happens when a replica lags or a region is cut off. See consistency models and CAP.
- Adapting cleanly when the interviewer changes a constraint, rather than defending the original design.
Example: the first 15 minutes of "design a web crawler"
- Scope (3–5 min). Ask what the crawl feeds (a search index), how many pages (1B/month), freshness targets, and whether JavaScript rendering is needed. Write down politeness as a hard requirement.
- Estimates (3 min). ~400 pages/s, ~40 MB/s, ~25 TB/month compressed; a 10B-URL seen set doesn't fit naively in memory, so mention a Bloom filter.
- Diagram (5–7 min). Frontier, fetchers, DNS and robots cache, page store, parser, URL filter. Walk one URL around the loop.
- Pick the deep dive. Offer the URL frontier (priority plus per-host politeness), since it's the genuinely hard part. Expect the interviewer to then change something: "now we need to re-crawl news sites every minute."
The full answer is in design a web crawler.
A four-week prep plan
- Week 1, fundamentals: caching, sharding, replication, consistency, queues. Our caching, sharding, and consistency primers are a fast refresher.
- Week 2, classic problems: URL shortener, rate limiter, news feed, chat, notification system, using the 45-minute framework every time.
- Week 3, infrastructure problems: web crawler, distributed cache, top-K, video streaming. Practise going deep on one component per problem.
- Week 4, mocks: timed practice with someone who interrupts and changes requirements, the way Google interviewers reportedly do.
Sources
- Exponent, "Google system design interview": tryexponent.com/blog/google-system-design-interview
- Hello Interview, Google L5 guide: hellointerview.com/guides/google/l5
- IGotAnOffer, Google L4 interview: igotanoffer.com/en/advice/google-l4-interview
- Candidate discussion on Blind: teamblind.com
FAQ
Does Google ask system design for L4?
Reports conflict. Many candidates say L3 and L4 loops focus on coding, with design either absent or folded into a coding round, while others report a design round at L4. From L5 up, a standalone system design round is standard, and L6+ candidates often get two. Ask your recruiter.
Should I use Google technologies like Bigtable or Spanner in my answer?
You can mention them as examples, but explain the properties you need (a wide-column store, globally consistent transactions) rather than relying on product names. Interviewers want reasoning, and they'll probe whatever you name.
Is Googliness part of the design round?
No. Googliness and leadership are assessed in a separate behavioural round. In the design round, collaboration still matters: how you take hints, handle changing requirements, and explain trade-offs.