The rubric senior interviewers actually use for system design

The five-axis rubric

Axis 1: Scoping. Did you ask clarifying questions that a real engineer would ask? Did you narrow the problem enough that the design can be complete in 45 minutes without hand-waving?

Axis 2: Scale math. Did you estimate traffic, storage, bandwidth, and latency requirements before drawing boxes? Were your numbers defensible?

Axis 3: Component choice. Did you pick technologies that fit the scale and latency targets? Did you defend the choice with at least one sentence per component?

Axis 4: Data modeling. Did you describe the hot data shape, the indexing strategy, the consistency requirements, and how reads differ from writes?

Axis 5: Operational readiness. Did you address failure modes, monitoring, deploy strategy, capacity planning, and cost profile?

Each axis is scored 1-5. Three is meeting bar for senior. Four is strong senior. Five is staff or above.

What the rubric rewards

Asking "what is the scale target" before drawing a box. At Meta E6 or Google L6 level, interviewers watch for candidates who defer design decisions until scale is pinned.

Doing capacity math visibly. Compute QPS from DAU. Compute storage from QPS times retention times record size. Compute bandwidth from QPS times average payload. Compute cache hit rate assumption and defend it.

Defending component choices. "I would use Cassandra for the shortened-URL store because the workload is write-heavy, range queries are not needed, and we benefit from multi-region replication" scores higher than "I would use Cassandra."

Addressing the failure mode for each component. What happens if the cache dies. What happens if the primary database is unavailable for ten minutes. What happens if the ID generator service is unreachable.

What the rubric punishes

Hand-waving about consistency. If you say "eventually consistent" or "strong consistency," the interviewer will follow up and ask what specifically happens on a stale read.

Buzzword architecture. Drawing a diagram with Redis, Kafka, Elasticsearch, Flink, and Kubernetes without explaining why any of them. Scored low for every axis.

Skipping the scale math. Going straight to components. Loses points on axis 2 regardless of how good the component choice is.

Ignoring operational concerns. Scoring axis 5 as a zero if you never mention monitoring, deploy, or cost.

How to prepare

Practice the scoping conversation first. Memorize the four or five questions you always ask (scale, latency, consistency, failure tolerance, read-write ratio). Rehearse them until they are automatic, because the interviewer is grading how natural this feels.

Practice the capacity math cold. You should be able to compute requests per second, storage per year, and bandwidth per second for any design in under ninety seconds.

Build a component playbook for the top ten categories: relational vs non-relational, cache types, message queues, object stores, CDNs, search, streaming, service mesh, API gateways, rate limiters. One paragraph per category on when to reach for each option.

Trace operational failure scenarios for each component choice. For every technology you pick, you should know the top three ways it fails in production and what the mitigation looks like.