Google system design interview questions
Google's system design rounds are conversation-driven: a deliberately open prompt, then 45 minutes in which your interviewer keeps raising the scale, the constraints, and the failure modes to see how you think.
Strong candidates spend the first five minutes on requirements and back-of-envelope numbers, sketch a baseline that merely works, then iterate. The rubric rewards articulating trade-offs far more than reproducing a memorized architecture.
These warmups are Google-flavored on purpose — autocomplete, trending queries, YouTube counters, presence cursors. Practice thinking out loud: silence is the one thing that reliably sinks this round.
Practice these Google questions out loud
A voice AI interviewer asks them in Google's style, probes your answers, and scores you at the end.
System design
What good answers include
Trie or n-gram candidate generation from query logs, ranking by frequency/recency/personalization, caching plus edge serving, and a story for trending-query updates.
Common mistakes
Only the data structure with no ranking or scale story; ignoring head vs tail query distribution; no latency budget.
System design
What good answers include
Heavy-hitter structures or count-min sketch per shard merged periodically, approximate counting with stated error bounds, and hot-shard mitigation.
Common mistakes
Exact counting of every query with no memory math; one globally sorted list computed per request; no discussion of approximation trade-offs.
System design
What good answers include
Batched incremental counting rather than per-view writes, dedupe and bot filtering at the edge, eventual consistency with cached reads, and a reasoned stance on exactness.
Common mistakes
A SQL counter updated on every view; insisting on exact real-time counts; ignoring abuse entirely.
System design
What good answers include
Fan-out on write vs read trade-off, a per-mailbox changelog driving per-device sync, idempotent updates, and eventual consistency that converges rather than oscillates.
Common mistakes
One global counter with no sync story; ignoring offline clients; no reconciliation mechanism.
System design
What good answers include
Aggregated, anonymized location signal; per-venue baseline models compared against live ratio; minimum cohort thresholds for privacy; a sensible refresh cadence.
Common mistakes
Treating it as a pure counting problem; no privacy discussion (it will come up at Google); no handling of empty venues.
System design
What good answers include
Offline ML inference at upload (labels/embeddings), a per-user index structure, query embedding plus nearest-neighbor search, and cost/latency reasoning for the ingest pipeline.
Common mistakes
Running inference at query time over raw photos; no per-user sharding story; treating synonyms and multiple languages as trivial.
System design
What good answers include
A priority queue scored by freshness/change-rate and importance, per-host politeness and rate limits, content-fingerprint dedupe, and a re-crawl schedule.
Common mistakes
A breadth-first crawl with no politeness; ignoring robots.txt; no estimate of how often pages change.
System design
What good answers include
Per-document pub/sub with presence channels, ephemeral high-frequency updates (no persistence), heartbeat and disconnect timeouts, and fan-out limits at scale.
Common mistakes
Persisting cursor positions; one global channel for all documents; no timeout story for dead clients.
System design
What good answers include
Versioned object storage plus a per-file metadata changelog, client-side operation queues, conflict detection via version vectors with a concrete resolution UX, and lazy sync for constrained devices.
Common mistakes
Silent last-write-wins; a server treated as the only source of truth with no offline queue; no story for mobile.
System design
What good answers include
A distributed algorithm choice (token bucket / sliding window), shared counter store versus local decisions with sync, an explicit fail-open or fail-closed stance, and keying granularity.
Common mistakes
An in-memory limiter per node; no answer for limiter outage; ignoring clock skew across regions.
More company packs
Amazon
Leadership Principles questions — Customer Obsession, Ownership, Dive Deep — with bar-raiser-style probing.
Googleyness stories — unasked initiative, data-driven persuasion, respectful challenge.
Meta
Impact-first questions: what did YOU do, how was it measured, what broke when you moved fast.
Microsoft
Growth-mindset stories — feedback, disagreement, mistakes that improved systems.
Deloitte
Fit stories plus short business cases — profit trees, cost cuts, program rescue.