One of three independent system design rounds at Waymo for an ML System (runtime/optimization) role. This round focuses on ML accelerator techniques and efficiency optimization. Topics covered include: Quantization-Aware Training (QAT), knowledge distillation, model evaluation (model eval()), contrastive learning, kernel optimization, memory layout strategies, and kernel fusion. Candidates are expected to discuss both high-level algorithmic choices (e.g., when to apply quantization vs. distillation) and low-level hardware/software efficiency concerns (e.g., memory access patterns, kernel fusion for reducing memory bandwidth pressure). A companion system design round covers inference system design for 100M DAU (back-of-envelope estimation of memory, bandwidth, latency; OOM mitigation). A third system design round covers ML framework design.
Naive approach with serious trade-off — being authored.
Solid baseline with reasonable trade-offs — being authored.
Production-grade approach with explicit trade-off rationale — being authored.
Naive approach with serious trade-off — being authored.
Solid baseline with reasonable trade-offs — being authored.
Production-grade approach with explicit trade-off rationale — being authored.
Naive approach with serious trade-off — being authored.
Solid baseline with reasonable trade-offs — being authored.
Production-grade approach with explicit trade-off rationale — being authored.
Cover happy path. Clarify scope. Identify the obvious bottleneck. Pick a reasonable storage and reasonable scaling approach.
All of the above plus: explicit failure handling, durability vs latency trade-offs, choose the right batching/caching strategy, articulate why.
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.
Common mistakes: Conflating PTQ and QAT without distinguishing training-time vs. post-training calibration; Missing low-level memory layout implications when discussing kernel optimization; Not connecting optimization choices to hardware roofline model (compute-bound vs. memory-bandwidth-bound); In the debug coding companion round: missing tensor aliasing bugs (Matrix.zeros), missing axis=1 in to_ndarray, misunderstanding truncation behavior in from_ndarray
What passers do: Demonstrating depth across both algorithmic (QAT, distillation) and systems-level (kernel fusion, memory layout) topics; Linking efficiency techniques explicitly to hardware constraints (bandwidth, FLOP/byte ratio); Clear, structured discussion of tradeoffs for each technique
Why people fail: Being caught off-guard by the debug coding round (numpy/tensor aliasing bugs); the companion debug round was noted as the most likely failure point; Surface-level answers on kernel optimization without concrete hardware or implementation knowledge
Edge cases probed: Interaction between eval() mode and quantization (e.g., batch norm freezing during QAT); Memory aliasing bugs in tensor operations (e.g., Matrix.zeros aliasing, to_ndarray missing axis=1, truncation of remainders in from_ndarray)
Alternative approaches: Compiler-level optimization (TVM, XLA, TensorRT) (Automated and portable, but may not reach hand-tuned kernel performance; requires understanding of compiler IR and cost models.); Pruning + sparse execution (Can yield high compression ratios but requires hardware/library support for sparse ops (e.g., NVIDIA A100 structured sparsity); accuracy recovery is non-trivial.)