Senior Engineering Interview Handbook / Chapter 965
Appendix A - Senior Competency Matrix
A practical reference for calibrating observable interview evidence across problem framing, coding, architecture, production, delivery, leadership, and communication.
Page tools
Read the evidence, not the person
Use this matrix after a mock interview, transcript review, story-bank pass, or project-dossier review. It answers a narrow question: what level of judgment did the available evidence make visible? It does not determine a person’s engineering level, reproduce a company’s career ladder, or turn a partial interview sample into an objective score.
The four bands describe increasingly broad evidence:
- Insufficient evidence: the observation is missing, too vague, or too contradictory to support a conclusion. This is not proof that the candidate lacks the skill.
- Mid-level evidence: the candidate executes well inside a bounded problem, usually with the goal, scope, or decision boundary already supplied.
- Strong senior evidence: the candidate owns an ambiguous problem through decisions, trade-offs, delivery, and consequences across a meaningful scope.
- Staff-shaped evidence: the candidate changes how multiple teams make or carry out decisions through strategy, standards, platforms, or other durable leverage.
Staff-shaped does not mean “a more impressive senior answer.” It requires genuinely broader scope and influence. A senior role may neither need nor reward that shape, and a flash of broad influence does not repair weak evidence in a round’s primary competency.
The competency matrix
Read one row at a time. The cells are anchors, not scripts; an answer need not contain every phrase in a cell to belong in that band.
| Signal | Insufficient evidence | Mid-level evidence | Strong senior evidence | Staff-shaped evidence |
|---|---|---|---|---|
| Problem framing | The goal, user, constraint, or success condition remains unclear; the candidate starts from an untested interpretation. | Clarifies requirements and edge cases for a bounded task, then works within the supplied scope. | Turns ambiguity into goals, constraints, assumptions, non-goals, risks, and a decision plan; revises the frame when evidence changes. | Reframes a problem shared across teams, separates immediate delivery from strategic work, and creates a decision model others can reuse. |
| Coding fluency | The candidate cannot produce coherent, inspectable code or explain its important behavior; correctness remains unknown. | Produces working code for a familiar bounded problem, with some prompting around tests, complexity, or recovery. | Writes simple, readable code; states the invariant and operation costs; tests meaningful boundaries; and debugs from observed state. | Improves code beyond one solution through an appropriate interface, abstraction, migration path, or standard whose value is supported by the wider context. |
| Architectural judgment | Components or technologies are named without a causal link to requirements, ownership, or trade-offs. | Produces a plausible design for the obvious workload and can explain its main data flow. | Derives boundaries, APIs, data ownership, consistency, scaling, and evolution from requirements; makes the important trade-offs explicit. | Shapes a multi-team technical direction, platform boundary, or migration strategy and accounts for adoption, organizational constraints, and long-term option value. |
| Production judgment | Failure, data correctness, security, privacy, observability, rollout, and cost are absent or appear as generic afterthoughts. | Adds familiar controls such as tests, metrics, retries, or rollback when prompted, but does not yet connect them into an operating model. | Identifies concrete failure paths and blast radius; designs detection, safe rollout, recovery, ownership, and learning around the risks that matter. | Changes the production system across teams through standards, paved paths, risk governance, capacity policy, or learning loops with observable adoption. |
| Delivery and product judgment | Local technical activity is disconnected from the user outcome, sequence, adoption risk, or cost of delay. | Prioritizes tasks and delivers against a defined plan; can make local scope adjustments. | Chooses a responsible slice, makes value and risk visible, preserves reversibility where useful, and changes sequence as learning arrives. | Aligns multiple teams around a durable product and technical bet, including investment boundaries, migration or adoption strategy, and conditions for reversal. |
| Leadership and influence | The account relies on title, attendance, persuasion, or undifferentiated “we” claims; personal judgment and effect are unclear. | Helps teammates, communicates status, reviews work, and resolves local coordination with clear ownership. | Leads through ambiguity or conflict using decisions, mentoring, artifacts, and trust; distinguishes owned, influenced, delegated, and team work. | Builds mechanisms that improve leadership beyond the immediate project: standards, forums, decision rights, talent growth, or cross-team operating agreements. |
| Communication and reflection | The answer hides decisions in chronology, overstates certainty, resists challenge, or offers lessons too vague to reuse. | Explains a straightforward path clearly and answers direct questions, though caveats or learning may remain thin. | Structures reasoning around decisions, alternatives, evidence, and consequences; responds to challenge and names what changed afterward. | Turns experience into shared organizational memory or a reusable decision practice, while preserving uncertainty and the limits of transfer. |
Evidence bands are not a point total
Interview loops sample these signals unevenly. Coding fluency may be the center of one round and barely visible in a behavioral conversation. Communication is present everywhere, but it should make the work legible rather than fill every answer with narration. The target role also changes emphasis: production judgment may carry unusual weight for an infrastructure role, while product and delivery judgment may be central to a product-platform role.
Three distinctions keep the matrix honest:
- Missing is different from weak. “Retries were not discussed” is missing production evidence. “The candidate retried every failure indefinitely” is observable negative evidence. Record the difference.
- One example can contain several signals without proving all seven. A migration story may strongly support architecture, production, and leadership while saying little about current coding fluency.
- Contradictions require judgment. A strong design followed by a rollout plan with no recovery path is not resolved by averaging two rows. Record both observations and ask whether the risk is central to the role.
Companies define levels differently, and interview evidence is always partial. Use the bands to locate the next question or practice need, not to manufacture a hiring verdict.
Watch one answer gain altitude
Consider a project deep dive about a service that failed under retry load.
“We added monitoring” names an activity but leaves the failure, decision, and effect invisible. The matrix cannot support a production-judgment conclusion from that sentence.
“I added error-rate and latency alerts after the incident” is useful bounded execution. The artifact is visible, but the reader still does not know why those signals were chosen, how responders should act, or whether the failure could recur.
A strong senior account might explain that synchronized client retries amplified load, compare retry caps with server-side admission control, and choose a staged correction: cap attempts, add jitter, shed excess work, alert on budget burn, and assign a rollback owner. It would then report what changed in the next load test or incident. The altitude comes from ownership of the failure system, not from a longer vocabulary list.
Staff-shaped evidence would require a wider, real consequence—for example, turning the verified failure pattern into a shared client policy and rollout gate adopted by several service teams. Merely claiming that the same fix could scale across the organization does not create that evidence.
Use the matrix after practice
Choose the round or artifact you are reviewing, then write down only what was observable. A compact review is enough:
Round or artifact:
Primary signals sampled:
Strongest observation:
Most consequential missing evidence:
Any negative or contradictory evidence:
Band supported, with one sentence of rationale:
Next drill or revision:
What should remain out of this answer:
The last line prevents signal dumping. A coding answer does not improve when a candidate forces an organizational-leadership aside into it; a leadership story does not improve when technical detail is removed in favor of slogans. Keep the primary competency clear and add adjacent evidence only where it changes trust in the answer.
Across a complete loop, look for a defensible pattern rather than symmetry. Repeated missing evidence in a role-critical signal should change the preparation plan. A clear strong-senior account is more credible than inflating ordinary scope into staff language.