The Proof Problem
Senior design hires are coalition decisions. The hiring manager is testing capability. The cross-functional partner — Product, Engineering — is testing whether your judgment transfers to their problems. The executive sponsor is testing whether you reduce organizational risk. Same debrief room, different proof burdens. A portfolio case that satisfies one evaluator may be irrelevant to the person sitting next to them.
Your portfolio already carries diverse evidence types. Alibaba proves scale outcomes. TinyFish proves production-grade AI recency. The Trust essay proves how you reason about agentic systems. Forward-looking artifacts prove you can work a problem visually before shipping it. The skill is not having the evidence — you have it. The skill is knowing which form goes to which evaluator and when a form hits its ceiling.
This issue introduces three tools for that work.
Evidence taxonomy classifies each proof type by what it establishes and where it stops. The right column maps the full set.
Requirement diagnostics sorts posted requirements into gate, preference, or proxy by asking what failure made the requirement appear.
Process reading treats the interview loop as a partial org chart. Who sits in each session tells you how the company distributes design authority.
The Hiring Coalition's Burden of Proof
Six people evaluate you for a senior design role, and they write their assessments independently before anyone talks. Each is answering a different question: the recruiter wants a category, the design peer wants current craft, the executive sponsor wants a sentence they can repeat under questioning. Close five burdens and leave one open, and the gap shows up in the written packet before the debrief begins. This piece maps each evaluator's doubt, where your nonlinear path triggers it, and the evidence form that retires it.
What Each Proof Can Carry
At this level the search is rarely lost on evidence quality. It gets lost on assignment: which proof goes to which question. You have five distinct forms of evidence, each of which carries certain propositions well and certain ones poorly, and the recurring error is overloading a strong asset. The structural problem right now is that the forms most relevant to AI-native roles are the ones nobody can inspect without you in the room, and the forms anyone can inspect prove pre-AI track record. Here is the boundary for each form, then what leads, what supports, and what breaks across the four tier archetypes.
Every Job Requirement Is a Gate, a Preference, or a Proxy
"Shipped code to production" is a gate at Anthropic and a proxy at Maven. Same five words, different evaluation logic — and the positioning move changes depending on which one you're reading. Most requirements in a design-leadership posting exist because something broke. This piece gives you a three-category diagnostic — gate, preference, proxy — and applies it to six current postings on your target list: Anthropic, Adobe, Render, Ramp, Maven Clinic, and OpenAI. For each, the classification, the reasoning, and the move.
Reading the Interview Loop as Organizational Evidence
The interview schedule tells you more about the role than the job posting did. Who interviews you, in what order, at what seniority, and from which function — that's an unintentional org chart. A Director-level loop with no design leadership present means something specific. A player-coach posting where every session tests craft and none test strategy means something different from what the posting promised. This piece is a diagnostic framework for reading the loop's architecture before you prepare for it, so you know what you're walking into while you can still decide whether to walk.