Rubric: Senior Frontend Engineer
Purpose
Use this rubric to evaluate whether an engineer has the senior foundation required before moving into frontend architecture. Senior capability means the engineer can own complex product surfaces, reason about production constraints, and make local technical decisions with clear tradeoffs.
Scoring model
| Level | Meaning |
|---|---|
| 1 | Needs close guidance; decisions are mostly task-local. |
| 2 | Can execute known patterns but misses cross-cutting risk. |
| 3 | Owns features independently and handles common production concerns. |
| 4 | Anticipates system effects and improves team practice. |
| 5 | Teaches the capability and creates reusable standards. |
Capability rubric
| Capability | 1 | 3 | 5 |
|---|---|---|---|
| Platform depth | Uses browser APIs mechanically. | Explains rendering, networking, storage, forms, and runtime constraints for feature work. | Teaches platform tradeoffs and prevents framework-only reasoning. |
| Architecture decision quality | Chooses familiar tools. | Names tradeoffs, constraints, and rollback paths for local decisions. | Produces reusable ADRs and calibrates others. |
| Rendering/data architecture | Fetches data where convenient. | Separates route data, server state, client state, and mutation flows. | Designs route-level rendering and cache patterns for teams. |
| Performance diagnosis | Uses Lighthouse after a complaint. | Profiles slow routes and connects symptoms to bytes, main thread, layout, or network. | Establishes budgets and regression guardrails. |
| Accessibility/security/reliability | Fixes issues when found. | Designs forms, auth-sensitive UI, error states, and keyboard flows responsibly. | Makes quality requirements part of component and delivery standards. |
| Design-system thinking | Uses components consistently. | Avoids local forks and identifies reusable behavior. | Contributes durable component APIs and migration plans. |
| Observability and incidents | Reads logs when asked. | Adds useful client errors, Web Vitals, and release context. | Turns incidents into system improvements. |
| Cross-team influence | Works inside assigned team. | Coordinates with backend, design, and product on feature risks. | Raises quality of adjacent teams through examples and reviews. |
| Business alignment | Focuses on implementation. | Connects technical choices to user outcomes and delivery risk. | Frames technical investments in business terms. |
| Written communication | Writes tickets and PR notes. | Writes clear design notes and review summaries. | Writes decision records that survive handoff. |
Evidence to collect
- A shipped feature with documented tradeoffs.
- A performance or reliability improvement with before/after evidence.
- A component or interaction pattern that other engineers can reuse.
- A decision note or ADR that names alternatives.
- A post-incident or post-launch learning artifact.
Readiness signal
An engineer is ready to begin the senior-to-architect path when most rows are level 3 or above and at least two rows are level 4. Gaps below level 3 should be addressed through Part 0 before attempting capstones.