engineering-hiring-rubric

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: engineering-hiring-rubric
description: "Build an engineering hiring rubric and technical interview scorecard for evaluating software engineers at a specific level. Use when asked to create an interview rubric, design a hiring process, build a technical scorecard, or standardize engineer evaluation. Produces a full interview scorecard, behavioral question bank, technical question set with evaluation criteria, system design rubric, and debrief agenda."
---

# Engineering Hiring Rubric

Produce a complete hiring rubric and interview scorecard for evaluating software engineers at a specific role and level. The rubric must be specific enough that two interviewers who have never compared notes will score the same candidate within one level of each other. That requires: explicit behavioral anchors (what does "Strong Hire" look like vs. "Hire" for each competency), calibrated technical questions with written evaluation criteria, and a structured debrief format that surfaces signal rather than recency bias. Include calibration notes to help interviewers recognize and counter common evaluation biases.

## Required Inputs

Ask for these if not already provided:
- **Role** — backend, frontend, fullstack, SRE/platform, data, ML, or mobile engineer
- **Level** — junior (L3/IC2), mid (L4/IC3), senior (L5/IC4), or staff (L6/IC5); clarify the company's level naming if different
- **Team context** — what the team builds, team size, and what problems this hire will work on in the first year
- **Tech stack** — primary languages and frameworks for the technical questions; list the stack explicitly
- **Interview format** — which rounds are used (phone screen, coding, system design, behavioral, take-home); if not specified, produce a recommended format

## Output Format

---

# Engineering Hiring Rubric: [Role] — [Level]

**Role:** [e.g., Senior Backend Engineer]
**Level equivalent:** [e.g., L5 / IC4 / Senior]
**Team:** [Team name and one-sentence description of what they build]
**Tech stack:** [Languages and frameworks]
**Interview loop:** [List the rounds in order]

---

## 1. Role Definition and Level Expectations

### What This Role Does

[2–3 sentences describing the scope of work: what systems they'll own, what problems they'll solve, and who they'll work with. Make this specific to the team context provided.]

### Level Bar

Define the minimum bar for a Hire recommendation at this level. This is not the ideal candidate description — it is the floor.

| Dimension | [Level] Floor | One Level Below (No Hire) | One Level Above (Stretch) |
|-----------|--------------|---------------------------|---------------------------|
| Technical scope | [e.g., "Owns a service or major feature area end-to-end with minimal guidance"] | [e.g., "Completes well-defined tasks; needs guidance on scope and approach"] | [e.g., "Leads cross-team technical initiatives; sets technical direction"] |
| Problem solving | [e.g., "Breaks ambiguous problems into concrete sub-problems independently"] | [e.g., "Solves defined problems well; struggles with ambiguity"] | [e.g., "Identifies problems others miss; structures organization-level technical challenges"] |
| Code quality | [e.g., "Writes production-ready code; anticipates edge cases; reviewable without significant rework"] | [e.g., "Writes working code that requires significant review feedback"] | [e.g., "Sets code quality standards; designs reusable abstractions adopted by others"] |
| Communication | [e.g., "Communicates technical decisions clearly to peers and stakeholders"] | [e.g., "Communicates well with direct team; struggles with cross-team or stakeholder comms"] | [e.g., "Drives technical consensus across teams; writes documents others reference"] |
| Ownership | [e.g., "Sees work to production; monitors after deploy; follows up on issues proactively"] | [e.g., "Delivers assigned work; escalates issues but doesn't drive them to resolution"] | [e.g., "Owns outcomes across teams; improves team processes