Free New Hire Onboarding Checklist for Engineering

The new hire onboarding checklist is the new engineer's day-by-day to-do list for their first two weeks. It is shorter and more concrete than the full onboarding plan, which spans six weeks. The checklist exists because new hires need a finite, scrollable view of what they should be doing on Tuesday of week one, and the onboarding plan is too broad to answer that question.

The template below is the version that consistently lands. It is opinionated about pacing — one real PR by Friday of week one, owning a ticket by week two — because pacing is where most onboarding goes wrong. Slow first weeks compound; engineers who do not ship a first PR in week one often take twice as long to be productive.

When to use it

• Every new engineering hire, from intern to staff.
• Internal transfers between engineering teams.
• Contractors joining the team for more than a month.
• Any time someone is starting on a codebase they have not worked in before.

The template structure

This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.

NEW HIRE ONBOARDING CHECKLIST — [name]
Start date: [date]   Buddy: [name]   Manager: [name]

WEEK 0 — BEFORE DAY ONE
[ ] Laptop and accessories shipped
[ ] Email and Slack accounts created
[ ] Repo, cloud, and vendor accounts provisioned
[ ] Calendar populated with week one meetings
[ ] Welcome message scheduled in #team
[ ] This checklist shared with the new hire

DAY 1 — MONDAY
[ ] Manager 1:1 (30 min, no real work)
[ ] Buddy intro call (30 min)
[ ] Read: team README
[ ] Read: team operating manual
[ ] Read: code ownership matrix
[ ] Get local dev environment running
[ ] Push trivial PR (typo, comment, README clarification)

DAY 2 — TUESDAY
[ ] Read: last quarter's decision records (skim)
[ ] Read: most recent postmortem
[ ] Pick first real ticket with buddy
[ ] Watch any recorded team meeting from last month

DAY 3 — WEDNESDAY
[ ] Begin first real ticket
[ ] Buddy async check-in (written, end of day)
[ ] Meet someone outside the team (cross-team coffee #1)

DAY 4 — THURSDAY
[ ] Continue first ticket
[ ] Manager check-in (15 min)
[ ] Read: PR review SLA, decision authority map

DAY 5 — FRIDAY
[ ] First real PR open
[ ] Reflect: what was harder than expected?
[ ] Pick second ticket (multi-day this time)

WEEK 2 — DAYS 6–10
[ ] First real PR merged
[ ] Second ticket in progress
[ ] On-call shadow shift (if applicable)
[ ] Review someone else's PR (your first review)
[ ] Cross-team coffee #2
[ ] Manager 1:1 — first two-week retrospective

BY END OF WEEK 2
[ ] One PR merged
[ ] One PR reviewed
[ ] Two cross-team coffees done
[ ] Local dev fully working without buddy assistance
[ ] Names matched to faces of immediate team

THINGS TO FLAG TO YOUR MANAGER
  - Anything in the docs that turned out to be wrong
  - Any access you do not have but need
  - Any meeting that you were invited to but should not be in
  - Any topic where you would like a 1:1 with someone specific

How to use it well

• The day-one trivial PR is non-negotiable. The PR is not about the code change. It is about exercising the full toolchain on day one. Local setup, repo permissions, CI, review process, merge. Anything that fails surfaces immediately instead of in week three.
• One real PR by Friday of week one. The single best predictor of a smooth ramp-up. If the new hire is not in position to open a real PR by Friday, something is wrong — usually a missing access or an unclear ticket — and it is the manager's job to find it.
• Buddy check-ins should be async-friendly. A daily fifteen-minute written check-in works for distributed pairs better than five video calls. The buddy is for answering questions, not for ceremony.
• Cross-team coffees are not optional. They feel like the most disposable item. They are the highest-leverage item for the new hire not being a stranger six months in.
• The week-two retro updates the docs. The new hire is the last person who can see what is missing from the onboarding doc before they normalize it. Their first contribution to the team's documentation should be fixing the docs that brought them in.

What to skip

Skip wall-to-wall meetings in week one. A first week packed with introductions feels welcoming and is operationally a disaster — the new hire has no time to actually try to do anything, and they end week one having met everyone and shipped nothing. Two or three meetings a day, max.

Skip giving the new hire a "stretch project" in week one. The first real ticket should be small and clearly scoped. Stretch projects come in week three when the new hire has the context to push back on scope.

Frequently asked questions

Is this template free?

Yes. The checklist above is the template. Share it with the new hire on their first day; tailor the buddy and manager names.

Can I edit it?

Yes. Most edits: drop the on-call shadow if you have no on-call, add a security-training step if your company requires it.

Do I need to give my email?

No. The checklist on this page is the same as the download; the email is only for the newsletter.