Onboarding Software Engineers: The First 90 Days

Engineering onboarding succeeds on three things: a first commit shipped in week one, a named human who answers questions without judgment, and written 30/60/90 expectations both sides can point at. Teams that provide those three consistently ramp engineers in half the time of teams that improvise, and they catch the rare mis-hire at month two instead of month nine. This guide gives the plan, the manager’s checklist, and the signals to watch.

Onboarding is also where your hiring process either pays off or leaks: the candidate said yes to the role described in your candidate packet and interview process; the first ninety days is where they audit that description against reality. First-year attrition is mostly this audit failing.

Before day one

• Access ready: laptop, repos, environments, licenses, calendar invites, all working before arrival. A new engineer spending day two on IT tickets learns exactly one thing about your operational bar.
• A starter task chosen: small, real, shippable inside week one. Not a toy; a genuine fix or improvement with a code review and a deploy at the end. The point is the full loop (branch → review → ship) while stakes are low.
• An onboarding buddy named: a peer engineer, not the manager, whose explicit mandate is questions-without-judgment for ninety days.
• The role document re-shared: the intake summary or role definition the hire was evaluated against (Yogen teams have this as the Internal Intake Summary, and continuity from the Candidate Packet they saw during interviews). Expectations that survived the interview process should not be re-invented in week one.

The 30/60/90 shape

Write these down and share them day one. Vague ramp expectations produce anxious new hires and unfalsifiable evaluations.

Days 1–30: context and first commits. Ship the starter task in week one. By day 30: several small changes shipped, dev environment mastered, the on-call and incident basics understood (shadowing, not owning), and a map of who owns what. The measure is trajectory, not output.

Days 31–60: real work, supervised edges. A meaty task within one system area, code reviews given (not just received), first design discussion participation. By day 60 the buddy relationship goes from scheduled to as-needed.

Days 61–90: ownership. An area or component where they are the default reviewer, participation in planning with estimates of their own, possibly first on-call rotation with backup. By day 90, the team would notice their absence.

Adjust amplitude by seniority, not shape: a staff engineer’s “starter task” may be a design review rather than a bugfix, and their 90-day mark includes an opinion about direction (the candidate-side view is worth sharing with the hire directly).

The manager’s cadence

• Week 1: daily ten-minute check-in. Not status; blockers and questions.
• Weeks 2–12: weekly 1:1 with one standing agenda item: “what’s confusing or slower than it should be?” New hires see your process debt with fresh eyes exactly once; write down what they report.
• Day 30/60/90: explicit milestone conversations against the written expectations. “Here’s where you’re tracking, here’s what’s next” in both directions.
• Throughout: feed their questions back into the onboarding doc. Onboarding is a living artifact; every hire should make it shorter for the next one.

Early-warning signals (and the honest response)

Most ramp wobbles are environmental: unclear expectations, a missing buddy, an oversized starter task. Fix those first and fast. The pattern that is not environmental: by day 60, code reviews still require line-by-line rework, questions repeat after being answered and documented, and the day-30 conversation’s specifics did not move anything.

If that pattern holds at day 75, name it explicitly against the written 30/60/90, with a concrete two-week improvement target. This is uncomfortable and much kinder than silence: the cost of a bad hire compounds with time, and so does the unfairness to the person in the wrong seat. The full playbook for that branch is managing underperformance; the point here is that a written ramp plan is what makes an early, fair call possible at all.

Close the loop to hiring

Every 90-day outcome is a data point about your interview loop. At each milestone review, ask one extra question: did the loop predict this? Competencies that never predict ramp performance get rewritten in your scorecards; interview stages that predicted nothing get redesigned (loop design). Teams that run this feedback loop are the ones whose hiring measurably improves year over year, because onboarding is where hiring’s promises get graded.