Peer Review Onboarding Checklist

Onboard a new engineer into the team's code review practice — tooling access, codebase orientation, mentor-paired review shadowing, and a 30-day calibration check. Run by the engineering manager or tech lead when a new developer joins.

5 sections 18 steps Collects data
1

Review Standards Orientation

  1. Walk through the team's code review guide

    • 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.

  2. Share the definition of done and ready

    • 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.

  3. Confirm the new engineer has read the guide
    Collects list
2

Tooling and Repo Access

  1. Provision GitHub org and CODEOWNERS access

    • 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.

  2. Install local review and signing tooling

    • 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.

  3. Capture the engineer's GitHub handle
    Collects text
  4. Pair on the local build and test loop

    • 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.

3

Codebase and Architecture Walkthrough

  1. Tour the service catalog and ownership map

    • 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.

  2. Confirm if a designated review mentor is assigned

    • 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.

    Collects list
  3. Set up #review-buddies group review fallback

    • 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.

  4. Review recent migrations and incident PIRs

    • 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.

4

Shadowed Reviews

  1. Shadow the mentor on three live PR reviews

    • 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.

  2. Co-review a small bug-fix PR

    • 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.

  3. Lead a review on a feature-sized PR

    • 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.

  4. Capture the calibration debrief notes
    Collects paragraph
5

30-Day Calibration

  1. Hold the 30-day reviewer check-in

    • 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.

  2. Solicit author feedback from teammates

    • 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.

  3. Sign off on independent reviewer status

    • 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.

    Collects list Collects paragraph Collects signature

Use this template

Copy it to your account, customize the steps, and run it with your team in minutes.

Use this workflow Start free trial
Sections 5
Steps 18
Category Software Development
Price Free to start
Need a different process

Browse hundreds of free templates across every team and industry.

Back to template library

Related templates

More workflows your team can run.

Software Development

Backup and Recovery Checklist

View
Software Development

New Developer Onboarding Checklist

View
Software Development

User Acceptance Testing Checklist

View
Software Development

Backlog Prioritization Checklist

View

Run Peer Review Onboarding Checklist with your team

Customize the steps, assign roles, set a schedule, and keep a complete record for every run.

Use this workflow Start free trial