Developer Onboarding Checklist (2026)

0 of 23 completed

0%

Pre-Day-1 Setup (Manager/Admin)

Complete these before the new hire's first day so they can start coding immediately, not waiting for access.

Provision git platform access (GitHub/GitLab/Bitbucket)critical

Add the new hire to the organization, correct teams, and relevant repositories. They should be able to clone repos on day 1. Include access to the reporting tool (Gitmore) so their activity is tracked from the start.

Set up project management tool access (Jira/Linear/Shortcut)critical

Add them to the correct project and team boards. Pre-assign 2-3 onboarding tickets they can start on.

Add to communication channels (Slack, email groups)critical

Add to team channels, engineering-wide channels, on-call channels, and any service-specific alert channels. They should see team conversations from day 1.

Set up cloud/infrastructure accessimportant

Provision AWS/GCP/Azure IAM roles, staging environment access, and VPN credentials. Use least-privilege: read access to production, write access to staging.

Assign an onboarding buddyimportant

Pair the new hire with a team member (not the manager) who can answer questions, do pair programming, and provide social context. The buddy should have daily 15-minute check-ins for the first 2 weeks.

Prepare a welcome document with team normsnice-to-have

Include: team working hours, meeting schedule, PR conventions, on-call expectations, and how decisions are made. This prevents the new hire from having to guess at unwritten norms.

Day 1: Environment Setup

The new hire should be able to run the application locally by end of day 1.

Clone repositories and set up local development environmentcritical

Follow the project README to get the app running locally. If this takes more than 2 hours, the README needs updating — have the new hire document what was missing as their first contribution.

Verify CI/CD access and permissionscritical

Push a test branch to verify they can trigger CI, view build logs, and deploy to staging. Don't discover permission issues during their first real PR.

Install team tools (linters, formatters, IDE extensions)important

Provide a list of required tools and recommended IDE settings. Better: use a devcontainer or nix-shell that installs everything automatically.

Run the test suite locallyimportant

The new hire should run the full test suite and see it pass. This verifies their environment is correct and gives them confidence that tests work.

Week 1: First Contribution

Ship something small to production in the first week. This builds confidence and establishes the workflow.

Open and merge first PR (even if trivial)critical

A typo fix, documentation update, or small bug fix counts. The goal is to exercise the full workflow: branch, code, PR, review, merge, deploy. Get this done by day 3.

Complete a codebase orientation sessioncritical

A 60-minute walkthrough of the codebase with the onboarding buddy or tech lead. Cover: repo structure, key modules, data flow, deployment architecture, and where to find things.

Review 2-3 PRs from teammatesimportant

Reviewing code is the fastest way to learn a codebase. The new hire should review PRs and ask questions — this teaches patterns, conventions, and business logic.

Attend a standup and team meetingimportant

Introduce the new hire in standup. Have them observe team dynamics, learn who works on what, and understand the current sprint's goals.

Read the incident runbook for the team's servicesnice-to-have

Even though they won't be on-call immediately, understanding how incidents are handled provides context about reliability expectations and service architecture.

30-Day Milestones

By day 30, the new hire should be contributing independently on small to medium tasks.

Complete 5+ PRs including at least one meaningful feature or bug fixcritical

Beyond trivial fixes, the new hire should deliver at least one PR that involves understanding business logic and writing new functionality.

Conduct a 30-day check-in with the managerimportant

Review how onboarding went: what was helpful, what was confusing, what documentation was missing. Use this feedback to improve the onboarding process for the next hire.

Document something that was hard to discoverimportant

The new hire has fresh eyes — they notice gaps in documentation that the team has normalized. Have them document at least one thing they struggled to find or understand.

Shadow an on-call shiftnice-to-have

Pair the new hire with the on-call engineer for a week. They observe how alerts are triaged, incidents are handled, and the monitoring dashboards work. This prepares them for their own on-call rotation.

60-90 Day Milestones

Full independence and integration into the team.

Own and deliver a feature end-to-endcritical

By day 60, the new hire should take a feature from ticket to production independently — scoping, implementation, testing, and deployment. The buddy and manager support but don't drive.

Join the on-call rotationimportant

By day 60-90, the new hire should be confident enough to handle on-call. Start with a secondary on-call role (backup to a more experienced engineer) before moving to primary.

Present work in a team demo or engineering all-handsnice-to-have

Public visibility builds confidence and helps the new hire establish credibility with the broader engineering org.

Conduct a 90-day retrospectiveimportant

The manager and new hire review the full onboarding experience: what went well, what should change, and what the new hire's growth goals are for the next quarter.

Pro Tips

Expert advice

1

The biggest onboarding failure: new hires waiting for access on day 1. Provision EVERYTHING before they start

2

First PR by day 3 is the single most important onboarding milestone — it proves the workflow works and builds momentum

3

Have the new hire update documentation as they go — their fresh perspective catches gaps the team is blind to

4

Use Gitmore to track the new hire's first week of activity — it gives the manager visibility without micromanaging

5

Onboarding buddies should be volunteers, not voluntold. A reluctant buddy does more harm than no buddy

FAQ

Common questions

How long should onboarding take?

Productive on small tasks: 1 week. Independent on medium tasks: 30 days. Fully ramped: 60-90 days. If full ramp takes longer than 90 days, investigate whether the codebase is too complex, documentation is lacking, or the onboarding process needs improvement.

Should senior hires go through the same onboarding?

Yes, but faster. Senior hires still need access provisioning, codebase orientation, and to understand team norms. Skip the hand-holding on git workflow and PR process. Focus the orientation on architecture, business context, and team dynamics.

What's the most common onboarding mistake?

Treating onboarding as 'read the docs and ask questions.' Without structure, new hires feel lost and don't know what questions to ask. A checklist with clear milestones removes ambiguity and gives both the new hire and manager a shared definition of progress.

Who is responsible for onboarding?

The engineering manager owns the process. The onboarding buddy provides day-to-day support. The team shares responsibility for making the new hire welcome. Don't delegate onboarding entirely to HR — they handle logistics, not technical integration.

More Checklists