AO
AceOffer
·
Back
Waymo Common Problems

Data Storage and Schema Design

System DesigneasyLast reported January 2026
By AceOffer · Updated January 2026 · Reported 1× across 190+ candidate reports

Understanding the Problem

A system design / data modeling question (asked at Waymo phone screen) covering three interrelated topics: (1) How do you store large amounts of data at scale? — covering storage systems, partitioning, sharding, replication, and choice of database type (SQL vs NoSQL vs columnar, etc.); (2) How do you design database tables for a given use case? — covering normalization, indexing, foreign keys, and access-pattern-driven design; (3) What is a schema? — definition, purpose, schema-on-read vs schema-on-write, evolution strategies. The question lasted ~30 minutes and caught the candidate completely off guard (recruiter had indicated only mid/hard LeetCode, not system design).

Functional Requirements

Structured requirements coming soon. For now, see the full problem statement above and the deep-dive prompts below.

Non-Functional Requirements

Latency, throughput, availability, consistency targets — being authored.

The Set Up

Defining the Core Entities

Core entities (Request, Batch, Worker, Cache, etc.) — being authored.

The API

POST /endpoint → describe request shape GET /endpoint → describe response shape (API spec being authored)

High-Level Design

Component diagram + walkthrough mapping each functional requirement to a system flow — being authored.

Potential Deep Dives

These are the directions the interviewer is likely to push you. Each one has multiple valid solutions at different quality tiers.

1)How would you handle a table that grows to billions of rows? What changes to your schema? (when: Candidate mentions SQL databases)

Bad
Naive approach with serious trade-off — being authored.
Good
Solid baseline with reasonable trade-offs — being authored.
Great
Production-grade approach with explicit trade-off rationale — being authored.

2)How do you handle schema changes when you have no enforced schema? (when: Candidate mentions NoSQL)

Bad
Naive approach with serious trade-off — being authored.
Good
Solid baseline with reasonable trade-offs — being authored.
Great
Production-grade approach with explicit trade-off rationale — being authored.

3)What is the difference between schema-on-read and schema-on-write? When would you choose each? (when: Candidate defines schema)

Bad
Naive approach with serious trade-off — being authored.
Good
Solid baseline with reasonable trade-offs — being authored.
Great
Production-grade approach with explicit trade-off rationale — being authored.

What is Expected at Each Level?

L4 / Mid-level
Cover happy path. Clarify scope. Identify the obvious bottleneck. Pick a reasonable storage and reasonable scaling approach.
L5 / SeniorTarget
All of the above plus: explicit failure handling, durability vs latency trade-offs, choose the right batching/caching strategy, articulate why.
L6 / Staff+
All of the above plus: organizational concerns (rollout, migration, on-call), quantitative analysis, multi-region considerations, what could go wrong with the proposed solution at 10x scale.

Insider Notes

**Common mistakes:** Being completely unprepared for system design when recruiter only mentioned LeetCode; Not structuring the answer — jumping between storage, tables, and schema without a clear framework; Failing to clarify the use case / access patterns before proposing a storage solution; Defining schema too narrowly (only as 'table columns') without discussing evolution or schema-on-read vs schema-on-write **What passers do:** Structured answer: clarify use case → choose storage system → design table → define schema; Discussing tradeoffs explicitly (SQL vs NoSQL, normalized vs denormalized); Demonstrating familiarity with real systems (Postgres, Cassandra, BigQuery, S3); Addressing schema evolution and versioning **Why people fail:** Complete lack of preparation for system design questions; Becoming flustered and unable to articulate any coherent framework; Giving only superficial definitions without tradeoffs or practical context **Edge cases probed:** Depth of understanding beyond surface-level definitions — candidate expected to discuss tradeoffs, not just name technologies; Schema evolution and backward/forward compatibility under live traffic **Alternative approaches:** Event Sourcing / Append-Only Log (Great for audit trails and temporal queries; schema evolution is easier; but read queries require replay/projection and storage grows unbounded without compaction.); Wide-Column Store (Cassandra/HBase) (Excellent for high write throughput and time-series data; schema is flexible per row; but poor for ad-hoc queries and joins — must design tables per query pattern.); Document Store (MongoDB) (Schema-less / flexible nested documents; easy iteration; but lack of joins and inconsistent schemas can lead to data quality issues at scale.)
Waymo · System Design · Last reported January 2026