Section 13: The Judges' Table - Final Summary & Candidate Scorecard

Executive Summary: This section turns the module into a grading tool. It replays the hour as the signals the interviewer was recording, then lays out a 100-point scorecard across five dimensions, each described by what a top answer and a point-losing answer sound like for this problem. Score bands map a total to a specific fix, and a final catalog shows where the question hides in real loops.

The boxes you drew for g_8Kd2 were worth about a quarter of the points. Did you notice, before anyone told you, that the clock and the result are the product? Did you hear "20,000-player Arena" and see a scheduled stampede rather than more games? You can't reliably earn points you can't name, so this section names them.

The Arc, Replayed as Signal

The module moved in six phases, each recording a different signal.

Four facts picked the architecture. 28K moves/s and 167 MB of live state fit one region, but Bengaluru against Virginia costs ~250 ms per round trip, and one outage would stop all chess: three cells. A crash that forgets a move the opponent already saw forks the game: persist-then-broadcast, one conditional write on ply = :n AND owner_epoch = :e. An Arena game in eu-west puts ~120 ms of backbone between Priya's ap-south gateway and her game: timing at her own gateway. And 30,000 games in a 10 s window at the top of the hour, 8.6× the normal creation peak: pre-scaling 10 minutes ahead and batched creation.

Key Insight: None of these signals is "knew DynamoDB" or "knew Glicko-2." Each is about letting a number or a stated rule pick the mechanism. The rule that decides the most comes from Section 1: charge a player only for the time they spent thinking. Gateway timekeeping, the TCP_INFO credit and the flag on the same ordered connection all follow from it.

Quick check before moving on: