The Design-Doc and RFC Read: Own It, Scope It, or Pass

You are looking at a senior or staff candidate and you want to know, before the panel, whether they can own architecture decisions at the level you are hiring for. This guide is for engineering managers, technical founders, dev-rel leads, and technical sourcers who need to grade that judgment from the written record. It gives you a scoring rubric and a discovery procedure to read one named person's public design docs, RFCs, and ADRs and reach a defensible verdict: own it, scope it, or pass.

Most writing on this topic explains what an RFC is and hands you a template. That is not the job here. The job is to grade the judgment of one specific person from the artifacts where systems-design reasoning actually lives, and to translate that read into a level call you can defend in a debrief.

Why read design docs instead of code or talks

Design docs, RFCs, and ADRs are the only public artifacts where architecture reasoning is written down in full. A code-review thread shows how someone responds to a change; a conference talk shows how they present a finished idea; a design doc shows the decision being made, with the alternatives, the trade-offs, and the open questions still exposed. That is the surface you want to grade.

Three terms, defined once. A design doc proposes a whole system and argues why one solution best satisfies the goals. An RFC (request for comments) is a design doc put through a public review process before a change is accepted. An ADR (architecture decision record) captures one architecturally significant decision in a short, numbered, durable record.

The supply math is the reason to do this at all. Title filtering over-selects.

With that ratio, a title filter leaves you with a crowded senior pool and a staff pool that is partly mislabeled in both directions: people doing staff-scope work without the title, and people carrying the title on single-team scope. A graded doc read is how you separate them. And the cost of getting it wrong is not a title quibble: the staff-to-senior gap widens from roughly 30 percent base pay to closer to 80 percent total comp once stock is counted. You are calibrating a large number.

The six dimensions that carry the signal

Score every doc on six dimensions: context, goals and non-goals, alternatives considered, decision and rationale, consequences and trade-offs, and open questions. Published templates converge on this spine, which means you can grade a Google design doc, a Nygard ADR, and a Rust RFC against the same rubric even though they name the sections differently.

The table below maps the three canonical formats onto the shared dimensions. Use it to find the right section fast regardless of which format the candidate wrote in.

Notice what the table exposes. The base Nygard ADR format - four sections: Status, Context, Decision, Consequences - has no mandatory alternatives or open-questions section at all. MADR adds explicit decision drivers and considered-options-with-pros-and-cons precisely because the base format lets authors skip the reasoning. When you grade an ADR written in the raw Nygard format, you are grading what the author chose to include beyond the minimum.

Not all six dimensions carry equal weight. Context, decision rationale, and trade-offs are necessary but easy to produce once a system exists. The three that actually separate candidates are alternatives considered, non-goals, and open questions. Those are the sections templates cannot auto-fill with substance, and they are where judgment either shows up or does not.

Why alternatives is the load-bearing section

The alternatives-considered section exists to force thinking about what options were available to achieve the goals. Its purpose is to say why the loser lost, specifically enough that a reader a year later can decide whether the reasoning still holds. That is a high bar, and it is where screening pressure already concentrates: the Rust RFC process explicitly notes that RFCs which are disingenuous about the drawbacks or alternatives tend to be poorly received. So a candidate who writes a real alternatives section has already survived a filter. A candidate who writes a hollow one has shown you the gap.

Why non-goals detect staff scope

Non-goals are not negated goals. They are things that could reasonably be goals but are explicitly chosen not to be goals. Anyone can list goals. Choosing what could belong in scope and declining it is the scope-setting act that separates the engineer who defines the problem from the one who executes a defined problem. When a doc names sharp non-goals, you are seeing the judgment that distinguishes staff-level framing from senior-level execution.

How to find one candidate's public docs

Search GitHub for the candidate as a pull-request author, not merely a committer, in RFC repositories and ADR folders. That distinction is the whole discovery problem, because authorship is what you are grading.

RFC repositories follow a predictable shape. The text/ directory contains accepted RFCs numbered sequentially, and accepted Rust RFCs get an id equal to their PR number. The pull requests themselves, both open and closed, represent active proposals and rejected ideas. ADRs are stored in the repository they relate to, numbered sequentially, and never deleted; superseded decisions are marked, not removed, commonly in a doc/adr/ folder.

Authorship is separable because of how these repos work. The RFC file is renamed to the PR number, and edits are made as new commits to the pull request with explanatory comments. So the PR author, the commit history, and the responses in the review thread together distinguish a real author from a co-author or a template-filler. Read the thread: did this person defend the design under hard questions, or did someone else do the arguing?

This is the part that is slow by hand: separating PR authorship from committer noise across repos, then confirming the person defended the design in the thread. If you are starting from a name rather than a repo, Refolk lets you find people by the artifacts themselves rather than by title.

The scoring procedure

Run every candidate through the same seven steps. Steps 1 through 5 are reader or sourcer work on the artifacts; steps 6 and 7 are the hiring manager's level call. Budget roughly two to three hours for a candidate with two or three substantive docs.

Use a fixed rubric so two reviewers reach comparable scores. Here is one you can copy.

Candidate: ______   Doc: ______   Authorship: solo / co-authored / template-fill   Date vs implementation: before / after

Context/problem        [0-3]  evidence: "..."
Goals and non-goals    [0-3]  evidence: "..."  (non-goals named? Y/N)
Alternatives considered[0-3]  evidence: "..."  (losers named with still-valid reasons? Y/N)
Decision and rationale [0-3]  evidence: "..."
Consequences/trade-offs[0-3]  evidence: "..."  (real costs admitted, not just benefits? Y/N)
Open questions         [0-3]  evidence: "..."

0 = absent  1 = heading present, no substance  2 = substantive  3 = reasoning a reader could falsify a year later
Honesty gate: fails if alternatives OR trade-offs scores 0-1. A failed gate caps the verdict at "needs scoped direction".
Blast radius: single-team (senior) / cross-team or multi-system (staff)

The 0-to-3 anchors matter. A score of 1 means the heading is present but empty, which is the trap this whole guide exists to defuse. Reserve 3 for reasoning that is specific enough to be falsified later, because that is the standard the alternatives section is supposed to meet.

How this read goes wrong

The failure modes below are where good readers reach bad verdicts. Each one is a specific check, not a vague caution. Treat this as the core of the method.

Two of these deserve extra weight because they flip a verdict in opposite directions.

The first is heading-completeness. Google teams start from standard templates pre-filled with section descriptions, so every section being present is expected, not impressive. A reviewer who scores on structure will reward a template-filler as a strong architect. The defense is the honesty gate: if alternatives or trade-offs is empty, the completeness is cosmetic.

The second is the retrospective trap. The clearest Google design docs tend to be retrospective ones summarizing a system already running. A doc written after implementation reads as crisp judgment when it is really hindsight. Check the timestamp against the first commits of the system it describes, and weight pre-implementation reasoning more heavily, because that is the reasoning that was made under uncertainty.

The rotted-log failure is quieter but it costs you a different thing: credibility. A folder of numbered ADRs can describe PostgreSQL-over-MongoDB while the code now runs on DynamoDB. That does not mean the author has bad judgment; it means the record is stale. Read the status fields and supersession links before you treat an old decision as the candidate's current thinking.

Mapping the score to a level

Scope, not code quality, is what separates staff from senior. Senior engineers own deep execution within a single team; staff engineers own technical outcomes spanning multiple teams, systems, or business domains. Will Larson's framing is worth holding in mind: senior is the career level at most companies, and most companies have no expectation that you go from senior to staff. So a doc that proves excellent single-team execution is a success signal, not a staff signal.

Use the blast radius of the doc as the primary level evidence, and read problem framing as the secondary signal.

The two-variable call is cleaner as a matrix. Judgment quality is one axis; scope is the other. The combination is the verdict.

The bottom-right quadrant is the dangerous one. A doc with broad blast radius but hollow alternatives is a candidate claiming staff scope without the reasoning to support it. Do not let the scope flatter the judgment. The honesty gate in the rubric exists to catch exactly this case.

Geography changes how hard you must lean on this read. The US staff pool is large; the UK pool is not.

Where the titled pool is thin, the doc read is not a nice-to-have; it is the primary way to find staff-scope operators who have not been promoted yet.

Keep the read current and defensible

Before you call the job done, verify the read against the checklist below. The goal is a written verdict that survives a hiring debrief: a score, a scope classification, and a quoted line of evidence for each.

Two habits keep this method honest over time. First, re-read the artifact, not your notes, when a candidate resurfaces; decision logs rot, and a doc you scored well a year ago may now describe a system that was torn out. Second, calibrate across reviewers by having two people score the same doc independently before comparing, because the heading-completeness trap catches different people differently. If your scores diverge by more than one point on alternatives or non-goals, that is a sign one of you is reading structure where the other is reading substance.

The read is defensible because it is anchored in quoted evidence and a fixed rubric, not in impression. That is what makes it something you can put in front of a panel and something you can defend when the comp number attached to the verdict is large.