engineering-hiring-rubric
# Engineering Hiring Rubric This Claude Code skill generates a complete, structured hiring rubric and technical interview scorecard for evaluating software engineers at a specific role and level. Use it when designing a hiring process, creating or standardizing interview rubrics, building technical scorecards, or establishing consistent evaluation criteria across multiple interviewers. The output includes behavioral anchors with explicit examples for each performance level, calibrated technical questions with detailed evaluation criteria, system design rubrics, a question bank, and a structured debrief format designed to reduce common interviewer biases.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/engineering-hiring-rubric && cp -r /tmp/engineering-hiring-rubric/plugins/pm-engineering/skills/engineering-hiring-rubric ~/.claude/skills/engineering-hiring-rubricSKILL.md
# 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 and systems beyond their own work"] | --- ## 2. Interview Loop Structure | Round | Format | Duration | Interviewer | Competencies Assessed | |-------|--------|----------|-------------|----------------------| | Phone screen | Video call, technical questions | 45 min | [Hiring manager or senior engineer] | Problem solving, communication, basic technical depth | | Coding interview 1 | Live coding — [platform] | 60 min | [Engineer] | Coding, data structures, code quality | | Coding interview 2 | Live coding — [platform] | 60 min | [Engineer] | Algorithms, debugging, code quality | | System design | Whiteboard / shared doc | 60 min | [Senior/Staff engineer] | System design, scalability, technical communication | | Behavioral | Structured interview | 45 min | [Hiring manager] | Ownership, collaboration, growth mindset | | [Optional] Take-home | Asynchronous project | [X hours] | [Reviewer] | Code quality, thoroughness, real-world problem solving | **Interview coverage matrix:** Each competency dimension must be assessed by at least 2 independent interviewers. | Competency | Phone Screen | Coding 1 | Coding 2 | System Design | Behavioral | |-----------|-------------|---------|---------|--------------|-----------| | Coding | ○ | ● | ● | ○ | | | System design | ○ | | | ● | | | Problem solving | ● | ● | ● | ● | | | Code quality | | ● | ● | | | | Communication | ● | ● | ● | ● | ● | | Ownership | ○ | | | ○ | ● | | Debugging | | ● | ● | | | ● = Primary signal ○ = Secondary signal --- ## 3. Coding Interview Guide ### Question Selection Choose 1–2 problems per coding round. Problems should be solvable in 30–40 minutes with the remaining time for discussion and follow-ups. Prefer problems with multiple solution tiers so you can see how far candidates take their thinking. ### Problem Template **Problem: [Title]** *Prompt (read to candidate):* > [Problem statement — be specific. Include constraints (input size, value ranges). Avoid ambiguity that tests problem-reading rather than problem-solving.] *Example:* > Given a list of integers representing stock prices at each minute of a trading day, return the maximum profit you could achieve by making exactly one buy and one sell. You may not sell before you buy. **Clarifying questions a strong candidate will ask:** - [e.g., "Can the list be empty?" / "Are all values positive?" / "Can profit be negative — i.e., should we return 0 if no profit is possible?"] **Solution tiers:** | Ti
Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.
Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.
Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
Plan a trip that actually works with a disability or access need — confirm real accessibility (not just 'accessible' labels), book the assistance in advance, plan for equipment and medication, and build in the contingencies for when access breaks down. Use when someone says 'plan an accessible trip', 'travelling with a wheelchair/disability', 'book assistance for my flight', or 'will this hotel actually work for me'. Produces an access-verified itinerary, an assistance-booking checklist, an equipment/medication plan, and contingency scripts. Verify specifics with providers.
Request a reasonable accommodation at work or in education — frame it around the barrier and the adjustment (not your diagnosis), cite the right process, and navigate the back-and-forth constructively. Use when someone says 'I need a workplace accommodation', 'request reasonable adjustments', 'ADA/Equality Act accommodation', or 'how do I ask for accommodations for my disability/condition'. Produces the request letter, a barriers-and-adjustments map, disclosure guidance, and a plan for the interactive process. Not legal advice — routes to the formal process and to advocacy where needed.
Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.