Peer Review Onboarding Checklist

The tech lead walks the new engineer through the team's review guide in Notion or Confluence. Cover the PR size budget (e.g., 400 lines), required approvals, CODEOWNERS routing, and the team's stance on nits vs. blockers. Skim review on a 1,200-line PR is the most common failure mode this guide exists to prevent.

Cover what "done" means on this team: tests passing, changelog entry, feature flag wired if behind a flag, no new secrets in the diff, and migration reversibility checked. The DoD is what reviewers should be checking against, not personal preference.

Add the engineer to the GitHub org via SCIM/SSO, assign to the relevant team(s) so CODEOWNERS routes review requests correctly, and confirm 2FA is enforced. Verify they can clone a private repo and push a branch.

GitHub CLI (gh), the team's IDE review extension (e.g., GitLens, GitHub Pull Requests for VS Code), and pre-commit hooks (gitleaks or trufflehog for secret scanning, plus formatters and linters). Verify a signed commit lands green in CI.

Reviewers need to be able to check out a PR branch and run it locally. Walk through gh pr checkout, the project's test command, and how to read CI logs in Actions / CircleCI / Buildkite. Flaky tests should be flagged in #engineering, not silently re-run.

Open Backstage (or the equivalent service catalog) and walk through which services the team owns, who the on-call is for each, and where the runbooks live. Reviewers can't evaluate impact without knowing what's downstream.

A senior engineer pairs with the new hire for the first ~3 weeks of reviews. They co-review PRs, then debrief. If no mentor is assigned, the workflow branches to a fallback group-review setup.

If no individual mentor is available, route the new engineer's first reviews through a Slack channel where two seniors triage co-review. Less ideal than a named mentor (the SPOF risk shifts onto chat-channel attention) but better than reviewing alone.

Read the last two post-incident reviews and any DB migration that took longer than expected. The named-cases approach makes review checklists concrete: "don't add a column with a default to a 50M-row table" lands when the engineer has read the PIR where exactly that locked the table for four hours.

The mentor walks the new engineer through three real reviews of merging-soon PRs — what they're looking at, what they're skipping, where they leave comments vs. start a thread vs. request changes. Watch for migration safety, secret leakage, and test coverage on the changed paths.

New engineer leaves comments first; mentor reviews the comments before the author sees them. Calibrate tone (suggestion vs. blocker), specificity, and the line between style preference and team standard.

New engineer is primary reviewer; mentor is secondary. After approval, the two debrief on what got missed and what got over-flagged. Aim for a PR with a migration or a feature flag so the harder review patterns get exercised.

Engineering manager meets with the new engineer to walk through the PRs they reviewed in the first month. Look at comment volume, approval-without-comments rate, and whether they caught any real issues. The goal is to spot "LGTM without reading" patterns before they calcify.

Ask two or three engineers whose PRs the new hire reviewed: was the feedback specific, timely, and actionable? Did they feel reviewed-with rather than reviewed-at? Anonymous or attributed depending on team norm.

Manager confirms the engineer can review without a mentor co-reviewer, or extends the shadowed-review phase if calibration is still off. Update CODEOWNERS to include them on owned paths once signed off.