Growing the team this year meant hiring more junior developers than usual, and our old onboarding approach, a wiki page and good intentions, wasn't scaling. New hires would spend their first two weeks reading documentation of varying freshness, occasionally interrupting a senior developer with a question, and shipping their first real code sometime in week four or five if things went well. We built a structured pairing program instead and want to share what actually worked, what didn't, and what it cost us to run.
Why this matters
Pairing sessions are scheduled, not ad hoc; a junior developer pairs with a senior for a fixed two hours daily during their first month, which removed the awkwardness of asking for help on demand. That awkwardness was a bigger problem than we initially gave it credit for. New hires consistently told us in retrospectives that they'd sit stuck on something for thirty or forty minutes rather than interrupt someone who looked busy, and a scheduled, expected pairing block removes that hesitation entirely because asking questions during that window is the explicit point of the time, not an imposition on someone else's day.
We also assign a small, real ticket in week one rather than a toy project, since junior hires consistently told us the toy projects felt disconnected from what they'd actually be doing. A toy project teaches syntax and maybe the build tooling, but it doesn't teach the parts of the job that actually take new hires the longest to learn: how a pull request gets reviewed here, which parts of the codebase are safe to touch confidently and which need extra care, and who to ask about what. A small real ticket, chosen deliberately for low risk and a clear scope, teaches all of that in a way a toy project structurally can't.
- Pairing sessions are scheduled, not ad hoc; a junior developer pairs with a senior for a fixed two hours daily during their first month, which removed the awkwardness of asking for help on demand.
- We assign a small, real ticket in week one rather than a toy project, since junior hires consistently told us the toy projects felt disconnected from what they'd actually be doing.
What we changed
Code review turnaround time for new hires dropped from days to hours once a senior developer was explicitly assigned as their first point of contact. Before the program, a junior developer's pull request went into the same review queue as everyone else's, which meant a review might sit for a day or two behind higher-priority work, and for someone still building confidence, a day of silence after opening their first pull request reads very differently than it does for a five-year veteran. Assigning a specific senior as a named point of contact, with an expectation that their reviews get priority for the first month, fixed that almost immediately.
The biggest surprise was how much the senior developers got out of it too. Explaining fundamentals out loud regularly surfaces gaps in documentation nobody had noticed, because a senior developer who's worked in a codebase for years stops seeing the parts that are confusing to someone new; those parts have become invisible through familiarity. More than one outdated section of our internal docs got fixed specifically because a junior developer asked a question the docs should have answered but didn't, and the senior pairing with them realized it in real time instead of the gap sitting undiscovered for another year.
- Code review turnaround time for new hires dropped from days to hours once a senior developer was explicitly assigned as their first point of contact.
- The biggest surprise was how much the senior developers got out of it too; explaining fundamentals out loud regularly surfaces gaps in documentation nobody had noticed.
Making the time investment sustainable
The program costs real senior developer time, roughly two hours a day for a month per new hire, and we were skeptical it would pay off given how thin senior bandwidth already runs on most projects. We addressed that skepticism the only way that actually settles it: by measuring the outcome rather than debating the theory. We tracked time-to-first-independent-merge across cohorts before and after the change, along with a simple survey of how confident new hires felt at the thirty and sixty day marks.
We also had to be deliberate about not burning out the senior developers doing the pairing. Rotating who mentors each new cohort, rather than always defaulting to whoever's most senior or most available, spread the load and meant no single person carried the onboarding burden quarter after quarter. We cap it at one active mentee per senior developer at a time, and if two new hires start in the same week, they get two different mentors rather than one mentor stretched across both.
What we'd still change
Four cohorts in, new hires are shipping independently by week three instead of week six, which more than covers the investment in senior time. That said, the program isn't finished evolving. The two-hour daily block works well for the first two weeks but starts to feel like too much structure by week three or four, when most new hires are ready for more autonomy and the scheduled pairing starts to feel like it's in the way rather than helping. We're experimenting with tapering the schedule, dropping to three sessions a week in the second half of the month rather than keeping the daily cadence fixed for the entire onboarding period.
How we chose the first ticket
Picking the actual week-one ticket turned out to matter as much as the pairing structure around it. Too easy, and a junior developer finishes in an hour and spends the rest of the week feeling like busywork was assigned to keep them occupied. Too ambitious, and the ticket becomes a source of anxiety rather than confidence, with a new hire quietly convinced they're behind before they've even had a chance to get their bearings. We've settled on a rough profile: a bug fix or small feature that touches two or three files, has an existing test to model new tests after, and has a clearly defined "done" state that doesn't require judgment calls about scope. Tickets meeting that profile get tagged specifically for onboarding use, so a lead assigning first-week work isn't scrambling to find something suitable from scratch every time a new hire starts.
We also learned to be deliberate about the emotional side of week one, not just the technical scaffolding. Several new hires told us in retrospectives that the biggest source of anxiety wasn't the code at all, it was not knowing whether a question was "dumb" or whether they should have already known the answer. We started explicitly telling every new hire, on day one, that the pairing block exists specifically because questions during that window are expected and welcomed, not tolerated, and that framing alone measurably changed how quickly people started asking things instead of quietly struggling through them alone first.
Tracking outcomes without turning it into a surveillance exercise
Measuring whether the program was working required tracking a few numbers without making new hires feel like they were being scored during an already stressful period. We settled on three signals: time from start date to first independently merged pull request, time from start date to first pull request merged with zero review comments, and a self-reported confidence rating collected at thirty, sixty, and ninety days, deliberately not shared with the mentor assigned to that hire, so the survey would capture an honest read rather than something shaped by not wanting to seem ungrateful for the mentor's time. None of these numbers get used in a new hire's performance review; they exist purely to tell us whether the program itself is working, and we say that explicitly to every cohort so the metrics don't quietly become something people feel judged against.
How mentor selection actually happens
Assigning mentors turned into more of a deliberate process than we expected going in. Availability matters, obviously, but we also learned to weigh a mentor's own current workload and stress level, since a senior developer who's underwater on a deadline of their own tends to give distracted, rushed pairing sessions that a new hire can feel even when nobody says anything about it directly. We now check in with a prospective mentor about their current capacity before assigning a new cohort, rather than assuming seniority alone qualifies someone to take on a mentee at any given moment, and we've turned down otherwise well-qualified mentors more than once simply because the timing was wrong for them personally that quarter.
We'd also like better tooling around the handoff at the end of the program. Right now the transition from "paired with a dedicated mentor" to "part of the normal team rotation" is a bit abrupt, and a couple of new hires described a small confidence dip in week five once the structured support ended. A lighter-touch follow-up, maybe a weekly fifteen-minute check-in through month three instead of a hard cutoff, is the next thing we plan to test.