Backend Engineer Onboarding Checklist

Overview

A new backend engineer’s first two weeks decide more than their productivity — they decide whether the hire trusts the team’s process, how fast they dare to deploy, and whether they’ll still be here in a year. Unstructured onboarding wastes the first month of a new engineer’s contribution. Without a checklist, new hires spend days figuring out which repositories to clone, which Slack channels matter, and how to deploy their first change — and they form their opinion of the team’s competence from that chaos.

This checklist structures the first two weeks so new backend engineers become productive contributors quickly while absorbing team culture and technical standards. It’s designed to be copied, adapted to your stack, and improved after every hire — the feedback section at the bottom is part of the checklist, not decoration.

When to Use

Use this checklist when:

• A new backend engineer joins your team
• An engineer transfers from frontend or another specialization
• You’re standardizing onboarding across multiple teams
• You need to measure and improve your onboarding process

For the supporting documents this checklist references, see the engineering handbook template (coding standards, tooling, “how we work”) and the service ownership document (what the new hire will eventually own). Teams that run on-call rotations should also pair the Week 2 items with their incident and alerting documentation.

Prerequisites

Before the new hire starts:

• Hardware ordered and configured (laptop, monitors, peripherals)
• Accounts created (email, Slack, GitHub, cloud provider, VPN)
• Manager assigned and calendar blocked for first-week 1:1s
• Onboarding buddy assigned from the engineering team
• Access requests submitted for production read-only access

Everything on that list should be done before day one — a new hire who spends their first morning waiting for a laptop or a GitHub invite learns that the team doesn’t plan ahead, and that’s hard to unlearn.

Before Day One

The week before the hire starts is where onboarding is actually won or lost. The checklist’s first day assumes four things already exist, and each one fails in a predictable way when skipped:

• Hardware in hand. Ship the laptop so it arrives two working days early — customs, couriers, and apartment mailrooms all eat days. For office hires, the desk, badge, and peripherals should be ready before they walk in.
• Accounts provisioned. Email, Slack, GitHub org, cloud console, VPN, password manager vault. Test each login yourself with a fresh account if you can — “the invite expired” is a classic day-one stall.
• A buddy who’s actually free. Buddy duty needs planned capacity in the sprint. A buddy who’s heads-down on a deadline will answer questions in three hours instead of three minutes, and the hire learns to stop asking.
• The checklist itself, adapted. The generic version you’re reading is a skeleton — before the hire starts, swap in your real repo names, channel names, dashboards, and tooling versions. A checklist that names things gets used; one that speaks in placeholders gets skimmed once and forgotten.
• A first PR waiting. Pre-pick a trivial change — a typo in docs, a stale comment, a label cleanup — so the day-one “merge something” task isn’t a scavenger hunt.

The manager sends the new hire a short pre-start email: what to expect on day one, who their buddy is, and the checklist link so nothing on the first morning is a surprise.

Solution

# Backend Engineer Onboarding Checklist

## New Hire: ______ | Start Date: ______ | Manager: ______ | Buddy: ______

---

## Day 1: Welcome and Setup

### Administrative
- [ ] Complete HR paperwork and benefits enrollment
- [ ] Receive laptop and hardware setup
- [ ] Obtain building access badge / parking pass
- [ ] Set up email and calendar
- [ ] Join essential Slack/Teams channels
  - #general, #engineering, #backend, #incidents, #deployments
- [ ] Add profile photo and status to Slack
- [ ] Schedule 1:1s with manager, buddy, and team lead

### Development Environment
- [ ] Install required software (see engineering handbook for versions)
  - [ ] Git
  - [ ] Docker and Docker Compose
  - [ ] Node.js / Python / Java / Go (stack-specific)
  - [ ] IDE (VS Code / IntelliJ / GoLand) with team settings
  - [ ] kubectl and cloud CLI tools
  - [ ] Postman or API client
- [ ] Configure Git with company email and signing key
- [ ] Clone primary repositories
  - [ ] Main application repository
  - [ ] Infrastructure / deployment repository
  - [ ] Shared libraries / SDK repository
- [ ] Run the project locally following README instructions
- [ ] Verify local tests pass
- [ ] Make a trivial documentation fix and open first PR

### Access and Security
- [ ] Complete security awareness training
- [ ] Set up password manager with team vault access
- [ ] Enable MFA on all accounts (GitHub, cloud provider, VPN)
- [ ] Request and receive staging environment access
- [ ] Read and acknowledge data handling policies

---

## Week 1: Codebase Orientation

### Architecture and Systems
- [ ] Attend architecture overview session (recorded if unavailable live)
- [ ] Review system architecture diagram and data flow documentation
- [ ] Identify the 5 most critical services your team owns
- [ ] Understand the request lifecycle: client → load balancer → service → database
- [ ] Review API documentation (OpenAPI / Swagger)
- [ ] Run through the debugging guide for common local issues

### Code Standards
- [ ] Read team's coding standards document
- [ ] Review 5 recently merged PRs to understand review patterns
- [ ] Understand linting and formatting rules (run linters locally)
- [ ] Learn the team's testing philosophy (unit vs integration vs e2e)
- [ ] Review error handling patterns in the codebase

### Processes
- [ ] Understand the sprint/iteration rhythm (planning, standups, retros)
- [ ] Learn how to pick up work (ticket system, Kanban board)
- [ ] Attend sprint planning and retrospective as observer
- [ ] Understand on-call rotation and escalation procedures
- [ ] Review incident response runbooks

### First Contribution
- [ ] Pick up a "good first issue" (labeled in issue tracker)
- [ ] Open a PR following the team's PR template
- [ ] Receive and address code review feedback
- [ ] Merge first PR with buddy's guidance
- [ ] Verify change deploys to staging successfully

---

## Week 2: Deeper Integration

### Production Awareness
- [ ] Shadow an on-call engineer for one shift (non-interruptible)
- [ ] Review production monitoring dashboards
- [ ] Understand alerting thresholds and paging procedures
- [ ] Learn how to query logs in the team's log aggregation tool
- [ ] Review recent postmortems (last 3 months)

### Domain Knowledge
- [ ] Meet with product manager to understand current roadmap
- [ ] Review user-facing features and business logic with domain expert
- [ ] Understand data model and entity relationships
- [ ] Review integration points with external services
- [ ] Learn about compliance and regulatory requirements (if applicable)

### Ownership
- [ ] Identify the service or component you will own
- [ ] Review service ownership documentation
- [ ] Understand deployment pipeline for your service
- [ ] Learn rollback procedures for your service
- [ ] Add yourself to service on-call rotation (with supervision)

---

## Completion Verification

| Area | Verified By | Date | Notes |
|------|-------------|------|-------|
| Environment Setup | ______ | ______ | |
| Local Build Working | ______ | ______ | |
| First PR Merged | ______ | ______ | |
| Security Training | ______ | ______ | |
| Architecture Overview | ______ | ______ | |
| On-call Shadow Complete | ______ | ______ | |

## Feedback

**What was most helpful?**

**What was missing or confusing?**

**How long until you felt productive?**

**Recommendations for improving this checklist:**

How to Use This Checklist

Three roles make the checklist work, and the document only functions if each one knows what they own. The manager owns the outcome — they verify completion, run the check-ins, and unblock anything the new hire can’t fix alone (access requests, procurement, cross-team introductions). The buddy owns the day-to-day — a peer, not a mentor or manager, who answers “how do I…” questions within minutes rather than letting them pile up into blockers. Assign the buddy before day one and pick someone who’s been on the team long enough to know where the undocumented stuff lives. The new hire owns the checklist itself — they tick items off, they flag what’s missing, and they fill in the feedback section at the end.

The checklist is sequenced deliberately. Day 1 is about removing friction — hardware, accounts, a working local environment, and one trivial merged PR so the new hire ends the day having shipped something. Week 1 builds context: architecture, code standards, team processes, and a real (but small) first contribution. Week 2 shifts from learning to belonging: production awareness, domain knowledge, and the first step toward owning a service.

The document itself needs an owner — typically the engineering manager or a senior engineer — because a checklist nobody owns rots silently. Version it in the repo next to the code it describes, review it after every hire, and prune it quarterly. When a tool or process changes, the checklist changes in the same PR that makes the change, not in a separate “update the docs someday” task that never ships.

Two items carry disproportionate weight. The first PR on day one — a documentation fix is enough — turns “the new person” into “someone who ships” and flushes out every environment problem while there’s still time to fix it. The completion verification table — a shared document the manager and new hire sign off — prevents the quiet failure mode where everyone assumes onboarding happened and nobody checked.

The Buddy’s Checklist

The buddy gets their own mini-checklist — a role nobody explains is a role nobody does:

• Week 1: daily 15-minute check-in (a real meeting, not “ping me if you need anything”), sit together on the first PR, and answer every “stupid question” as if it were a reasonable one — because it is.
• Week 2: walk the hire through the dashboards, the deploy pipeline, and the last incident postmortem; introduce them to the people who own the adjacent services.
• Weeks 3–4: step back to a twice-weekly check-in and start reviewing their PRs as a normal reviewer — the training wheels come off gradually, not all at once.

The buddy is not a mentor (career growth) or a manager (performance) — they’re the peer who knows where the bodies are buried in the codebase. Rotate the role across hires so it doesn’t quietly become one person’s permanent side job.

Adapting the Checklist

The template is deliberately stack-agnostic — the backend-specific parts are the Week 1 and Week 2 sections, and even there the shape matters more than the items. Before your first hire, spend an hour replacing the generic items with your real ones: the actual repo names, the actual Slack channels, the actual dashboards. A checklist that says “clone primary repositories” gets read once; one that says “clone api-server, infra, and sdk-go” gets used.

Leave some items marked “if applicable” rather than deleting them — compliance training, for example, only applies to regulated domains, but removing the row means the next hire in a regulated team won’t think of it. The checklist grows by addition and shrinks by marking things N/A, not by deletion; that way the memory of “we once forgot X” stays in the document.

30-60-90 Day Onboarding Plan

The two-week checklist gets someone productive; the 30-60-90 plan gets them independent. Each phase has concrete goals and a check-in where the manager verifies them.

=== Day 30: Contributing ===

Goals:
  - Environment fully configured and working
  - First 3-5 PRs merged (bug fixes, small features, tests)
  - Participating in code reviews (reviewing others)
  - Understands team workflow (standups, planning, retros)
  - Has met all team members 1:1
  - Completed security and compliance training

Check-in: Manager + buddy review progress, identify blockers

=== Day 60: Owning ===

Goals:
  - Owns a service or component (primary reviewer for changes)
  - Has been on-call shadow for 2+ shifts
  - Participating in design discussions
  - Can deploy to staging independently
  - Can debug production issues with guidance
  - Has written or updated documentation

Check-in: Manager reviews ownership readiness, adjust scope

=== Day 90: Independent ===

Goals:
  - Fully independent on-call (with backup available)
  - Can deploy to production independently
  - Leading a small feature or improvement
  - Mentoring the next new hire (if applicable)
  - Has completed a postmortem or contributed to one
  - Performance review: on track for expectations

Check-in: Manager + skip-level, confirm successful onboarding

The checkpoints exist because “onboarding is done” is a fuzzy state — each check-in converts it into a yes/no question with a named owner. If a goal isn’t met at day 30, that’s process feedback: either the timeline was wrong, the support was missing, or there’s a real performance question to address early rather than at month six.

The plan pairs with the checklist rather than duplicating it: the checklist covers the first two weeks task by task, the 30-60-90 covers the quarter goal by goal. Use both — the checklist gets them to the end of week two, the plan keeps them moving after the checklist runs out.

Where Onboarding Fails

Most onboarding failures look like people problems but are process problems wearing a disguise:

• The hero-onboarding: one senior engineer does everything informally, knowledge lives in their head, and the checklist exists only when they’re on vacation. Fix: the checklist is the process — the hero becomes the owner who updates it.
• The checklist nobody trusts: it’s been untouched for two years, half the links are dead, and new hires learn to ask the buddy instead of reading it — which is correct behavior around a lying document. A stale checklist is worse than none because it misleads while looking authoritative.
• The week-one wall: the hire finishes the setup tasks by Tuesday and then drifts — no curated first issues, no introductions scheduled, nobody told them what “good” looks like this week. The checklist’s phase structure exists to prevent exactly this dead air.
• The silent struggle: remote or junior hires often hide confusion to avoid looking slow. The daily buddy check-in isn’t optional politeness — it’s the instrumentation that surfaces “I’m stuck” before it becomes “three weeks behind.”

The failure that’s easiest to miss is success-shaped: the hire ticks every box, says onboarding was great, and three months later still can’t deploy alone because nobody verified the skill, only the attendance. That’s what the completion verification table is for — “verified by” means someone watched it happen, not that the hire says it did.

Measuring Onboarding

A checklist without metrics can’t improve. Four numbers cover most of it:

Metric	Target	What it tells you
Time to first PR merged	< 3 days	Environment and process friction
Time to first production deploy	< 2 weeks	Confidence + pipeline health
Time to independent on-call	< 2 months	Depth of documentation
New-hire satisfaction (day 30/60/90 survey)	Improving over hires	The experience itself

Track them per hire and review quarterly — a rising time-to-first-PR is usually a tooling problem (slow laptops, broken dev setup), not a hiring problem. The feedback section of the checklist feeds the same loop: ask every new hire what was missing, outdated, or confusing, and fix the checklist within a week while the memory is fresh.

The day-30/60/90 survey needs only three questions, and they should be asked in writing so the answer isn’t colored by a meeting: “What surprised you most?”, “Where did you feel least prepared?”, “What would you change about your first two weeks?” Answers that repeat across hires are the backlog for the checklist owner.

Variants

Context	Adjustments	Notes
Senior engineer onboarding	Add architecture review, mentoring responsibilities, cross-team introductions	Expect faster completion (5-7 days instead of 10)
Contractor / consultant	Focus on project-specific repos, skip culture/team processes	Tighter timeline, specific deliverable focus
Intern / junior engineer	Add programming fundamentals review, pair programming schedule	Longer timeline, more structured guidance
Remote-first team	Add async communication norms, timezone coordination, virtual coffee chats	No physical setup; stronger emphasis on documentation
Team merge / acquisition	Add legacy system orientation, political sensitivity, new process adoption	Focus on integration rather than fresh start

Remote onboarding deserves a special note: everything that happens by osmosis in an office — overhearing how deploys work, watching someone debug — has to be manufactured. Over-document, record the architecture sessions, and schedule the informal contact (virtual coffees, a #random channel) explicitly rather than hoping it happens.

Internal transfers sit in a variant of their own: they skip most of Day 1 (they have hardware and accounts) but need more domain context than a fresh hire — they already know how the org works, what they lack is what this team owns. Compress the checklist to Week 1’s architecture and processes sections plus the ownership track, and keep the buddy — knowing the company isn’t the same as knowing the codebase.

What Works

The practices below come from teams that onboard repeatedly and measure it — the pattern they share is treating onboarding as a product: a documented process with an owner, instrumentation, and a feedback loop, rather than an event that happens to the new person.

1. Assign a buddy, not just a manager — buddies answer the “how do I…” questions managers can’t
2. Have the first PR ready on day 1 — a documentation fix or test addition builds confidence immediately
3. Record architecture overviews — live sessions are valuable but not repeatable; record for future hires
4. Measure time-to-first-PR — it’s the leading indicator of onboarding friction
5. Update the checklist after each hire — fresh eyes spot gaps immediately

Common Mistakes

These are the patterns that turn a two-week checklist into a six-month ramp-up:

1. Focusing only on technical setup — culture, relationships, and process knowledge matter as much as code
2. Throwing new hires at complex tasks too early — first contributions should be achievable in 1-2 days
3. Skipping production access explanations — new engineers need to know what they can and cannot touch
4. Not explaining the “why” behind processes — following rules without understanding creates cargo cult behavior
5. Forgetting to check in after week 2 — onboarding continues for 3-6 months; the checklist is just the beginning

Good onboarding also pays back in retention. The hire who ships on day one, has a buddy who knows their name, and sees a 90-day path to owning a service is the hire who refers their former colleagues. The checklist costs a few hours per hire; the alternative costs a resignation.

Troubleshooting

The failure modes below are about the process, not the hire — when onboarding goes wrong, look at the system first and the person second.

• The new hire is blocked on access for days: access requests went in too late or to the wrong queue — submit them a week before the start date, and keep a named owner for each request so “pending” isn’t an orphan state.
• Day 1 ends without a merged PR: the “trivial fix” wasn’t trivial — keep a curated list of doc fixes and label-gardening issues ready, and have the buddy drive the first PR together if needed.
• The buddy is too busy to help: buddy duty needs explicit slack in their sprint — if it isn’t planned capacity, it silently becomes zero capacity. Rotate buddies across hires to prevent burnout.
• The checklist says “done” but the hire is lost: items got ticked without verification — the completion table needs a verifier (manager or buddy initials), not just a checkbox.
• Every hire finds the same gap: the feedback section is being collected but not acted on — assign a checklist owner and close the loop within a week of each hire finishing.

Further Reading

• GitLab Handbook — Onboarding — how a fully-remote company structures onboarding at scale
• Atlassian Team Playbook — plays for team health, including roles and onboarding-adjacent exercises
• Stack Overflow Engineering — Onboarding — engineering culture writing, including onboarding practices
• Related on this site: the engineering handbook template for the document new hires read, and the code review checklist they’ll be using by week 2.