Software Engineer Performance Review Checklist

Export merged PRs, review comments authored, and commit count for the cycle window. GitHub Insights or a script against the REST API works; capture both volume and review activity, not just author commits.

Request structured input from 3–5 collaborators — at least one cross-functional partner (PM or Design) and one frequent code reviewer. Use a consistent prompt set so feedback is comparable across the team during calibration.

Open the goals document from the last review and mark each as met, partially met, or missed with concrete evidence. Goals carried forward without progress are a common gotcha — name the blocker rather than rolling them silently.

Pick 3–5 representative PRs spanning feature work, bug fixes, and refactors. Assess readability, test coverage, error handling, and how the engineer responded to review feedback. Cite specific PR numbers in the written review.

Look for design docs authored, RFCs reviewed, and architecture decisions where the engineer contributed. For senior+ levels, the bar is leading at least one cross-cutting design; for mid-level, thoughtful participation in design review.

Pull PagerDuty / Opsgenie history for the cycle. Note pages acknowledged, time-to-ack, incidents commanded, and PIR action items owned to closure. Don't penalize page volume — focus on response quality and follow-through.

Sample 5–10 reviews the engineer authored. Look for substantive feedback (not just LGTM on 800-line PRs), willingness to push back constructively, and mentorship of junior engineers in review threads.

Talk to the PM and designer the engineer worked with most. Did they engage early in scoping, raise feasibility concerns before sprint start, and communicate slips proactively? Cross-functional friction usually shows up here first.

Check Confluence / Notion / Backstage for docs authored or substantively updated. Runbooks for services the engineer owns should exist and be tested — undocumented services with a single SME are a real risk signal.

Pull velocity data from Jira / Linear for the cycle. Consistent under-delivery is a signal; consistent over-delivery may mean the engineer is sandbagging estimates or absorbing scope from teammates. Talk through outliers in the 1:1.

Count production bugs traced back to the engineer's changes during the cycle. Use Sentry / Rollbar tags or git blame on hotfix commits. One high-impact regression matters more than five trivial ones — assess severity, not just count.

Compare original story-point estimates to actual completion across the cycle. Look for the pattern of late-stage scope discoveries — those usually mean insufficient design upfront, which is coachable.

Walk the engineer's evidence against each axis of your leveling guide — scope, autonomy, technical depth, leadership. Be explicit about which axes are at-level, above-level, or below-level rather than giving a single composite rating.

Note any AWS / GCP / CKA certifications earned, conference talks given, internal tech talks led, or substantive open-source contributions. Application of new knowledge to shipped work matters more than the credential alone.

Write 2–3 specific, measurable goals tied to the leveling rubric — e.g., 'lead the design review for the billing migration' rather than 'grow as a tech lead'. Vague goals are the reason last cycle's goals were hard to assess.

Share the draft rating and written review with peer managers ahead of calibration. The point is to surface inconsistent rating bars across the org before the engineer hears the outcome — not to defend a number.

Walk through strengths, growth areas, and the rating in person (or video). Send the written review at least 24 hours in advance so the conversation is about discussion, not first reactions. Document what the engineer pushes back on.

Partner with HR to draft a 60- or 90-day PIP with concrete, measurable success criteria and weekly check-in cadence. Loop in legal review before delivery if the engineer is in a protected class or remote in a jurisdiction with specific termination rules.

Upload the signed review, calibration notes, and any compensation-change recommendation to the HRIS (Workday, BambooHR, Rippling). Confirm comp changes flow to payroll in time for the next cycle.