Onsite Design Doc Review

A newer onsite round, particularly common for EM candidates and increasingly for senior IC loops. The interviewer hands the candidate a design doc (sometimes one straight from the team's own backlog) and asks them to critique it — surface risks, propose alternatives, identify gaps. Requirements Format 55 minutes. First ~10 minutes to read the doc, then a guided discussion. Some candidates report the doc resembling an actual ongoing internal design — closely tied to the hiring team's domain. For EM loops, this round replaces a coding round and sits alongside Execution & Leadership and Technical Presentation. Also appears in SWE loops as the system-design slot itself — the doc-review format replacing a blank-page design round. What interviewers grade on Identifying the most important risks first, not exhaustively listing minor nits. Surfacing what is missing as well as what is wrong — the doc is usually intentionally incomplete. Suggesting alternative architectures with concrete tradeoffs. Calibration: knowing when to push back vs. when the author has clearly considered an angle. Communication: how a real review comment would read in a doc-comment thread. Notes The round is new enough that detailed prompts are not yet broadly leaked. Several candidates flag it as the round they had no time to prepare for. Treat it as a senior code-review at the architecture level: prioritize, justify, propose. This is the round where mocking with a peer who has reviewed many real design docs is highest-leverage. One recurring doc topic is the batched GPU inference API — the same fixed-batch family as the flagship inference-API design prompt, delivered as a flawed doc to critique. Constraints the doc pins (fixed batching, no auto-scaling, no rate limiting) are off-limits to redesign; work within them. Preparation Review three real design docs (your own or open-source) end-to-end and write a structured critique for each. Practice the 10-minute speed-read. Build a checklist of dimensions to scan: scope/goals, non-goals, alternatives considered, scale/cost estimates, failure modes, rollout/rollback, observability, security/privacy, migration. Have language ready: "the section on X is underspecified — specifically, I'd want to see Y and Z before I'd ship this."