Section 13: What the Panel Wrote Down - Final Summary & Candidate Scorecard

Executive Summary: This closing section turns the module into a way to grade yourself. We replay the arc as signal, lay out a 100-point scorecard with half its weight on architecture and deep dives (where the index-versus-data split is won or lost), name two archetypes that lose the hour, map score bands to remediation, list the prompts that are "design S3" in disguise, and close with a thirty-second answer tying Section 1's four hard problems to the parts that keep them.

The interviewer was never grading the box labelled "storage nodes," but whether you saw that 10 trillion objects and an exabyte are two sizing problems, whether eleven nines came from a mechanism or a wish, and whether Lumen's 2026/10/31/… prefix made you reach for a split or a shrug.

The Arc, Replayed as Signal

Each phase recorded one signal, and none of them is "knows S3".

Section 3 earned credit not for "10 trillion objects" but for what followed: 10T entries at ~200 B is a 2 PB index in ~40,000 partitions, while the 0.1% of objects over 10 MB hold 80% of the exabyte and size the 90,000 disks. Section 7 earned credit the same way: the RS(10,5) arithmetic lands near 10^-17 per year against a budget of 10^-11, and the strong candidate said so, then explained that an AZ loss, a firmware bug or a GC that deletes live data is what actually spends it.

Key Insight: The panel assumes you know the parts and tests whether you know which promise each keeps. Answer "Lumen's prefix hits 50K PUT/s at 9 a.m." with "the partition's limit is 3,500 writes/s, so the token bucket returns 503 Slow Down while the auto-splitter divides the range within a minute" and you have shown index, throttle and API contract in one reply.