What a code review exercise measures
Presenting a candidate with a realistic pull request containing deliberate defects — a race condition, an unvalidated input, a misleading abstraction, a missing test case — reveals how they read unfamiliar code, how they prioritize among issues of unequal severity, and how they communicate criticism.
This last dimension is the reason the format is undervalued. Most engineering time is spent reading and modifying code written by others, and a candidate's review tone predicts their effect on team velocity more reliably than their algorithmic fluency. A reviewer who leads with the security defect and frames the stylistic observation as optional is demonstrating judgment, not just knowledge.
What a systems design interview measures
Design interviews test the ability to reason under ambiguity: clarifying requirements, estimating scale, choosing between consistency and availability, identifying failure modes, and articulating what would be revisited at ten times the load. They surface how a candidate handles the absence of a correct answer.
Their weakness is rehearsal. The canonical prompts are widely circulated, and a well-prepared candidate can produce a fluent answer without having operated anything comparable. Anchoring the prompt in the actual domain the role will work in, and asking follow-up questions about operational consequences, substantially reduces this effect.
Sequencing the two formats
For implementation-focused roles, lead with the code review and treat design as a secondary signal. For architecture and principal roles, invert the order. For contingent placements onto an existing enterprise codebase, the code review is the stronger predictor of first-month contribution, because that is exactly the work the specialist will do.
Both formats should be time-boxed, scored against a published rubric, and calibrated across interviewers. Unstructured assessment reliably produces a decision that reflects the interviewer more than the candidate.
Closing the residual gaps
Neither format measures operational behavior under pressure, collaboration across function boundaries, or the willingness to document. A short incident retrospective discussion — describe a production failure you contributed to and what changed afterward — covers most of that ground in fifteen minutes.
The strongest assessment stack is narrow and layered: a domain-anchored code review, a scaled design conversation, and a behavioral incident discussion, all scored on the same rubric. Adding a fourth round rarely improves accuracy and reliably lengthens time-to-offer.