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.

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.

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.

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.

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.

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.