The codebase is big, it's years old, and it's about law. A new developer on my team walks into all three at once, and the first week decides a lot more than whether their laptop works. It decides whether in month three they ask the question or sit on it.
So the first week is planned, and the plan is built around a pull request.
A merge in the first week
The first task is to set up the project by following the onboarding document. The second task is to fix the onboarding document.
Something in it is always wrong. A step the last person skipped because they already had the tool, a command that changed, an environment variable nobody wrote down. The newcomer finds it, because they're the only one reading the document without knowing the answers, and they fix it, and they open a pull request.
In an ideal world it's merged before the week is out. I review it with the same care as any other change, and from that one small change they've seen the flow: branch, commit, pull request, review, merge. They've seen what a review comment looks like here before they've written any code that could be commented on. And the document is better for whoever comes next.
Every new hire tests the onboarding document, and it fails every time. That's fine, it's what the first pull request is for.
The mentor
One person on the team, not me, is the newcomer's mentor for their first month or two. Their job is to be interrupted. The mentor is the first contact for every question, including the ones the newcomer thinks are stupid.
Not me, for two reasons. The lead's answers come with weight, and a newcomer won't push back on them, which means they learn what I think instead of how things work. And the mentor learns something too. Explaining the project to someone is the fastest way to find out what you don't know about it.
Behind the mentor there's a co-mentor. When the mentor is away or buried in something, the co-mentor takes the question, and when the questions pile up, they share them. The newcomer never has to wonder who to ask.
When the mentoring ends, the mentor and the co-mentor both give their feedback. The mentor changes with every hire. By now most of the team has done it.
The first real ticket
Small, visible, and in a part of the app everyone knows. A field on a form, a filter, a column in a list. Something where the mentor can answer every question and the result shows up on screen.
The bug nobody can reproduce and the clever thing in the module with history come later, when the newcomer has seen enough of the codebase to recognise what the clever thing is for. I wrote about which tickets I keep for myself in Leading from inside the codebase, and the first ticket is the opposite of that list.
What matters is that it ships, with their name on it.
The rule I say out loud
Stuck for half an hour, ask. Not after an hour, and not "when I've tried everything".
I say it on day one and I say it again on day three, because by day three they've forgotten, and because the people who need to hear it most are the ones who'd never ask on their own. It's also in the development guidelines, so it's a team rule and not just something the lead likes.
The other half of the rule is on us: a question gets an answer, not a sigh. If someone asks the same thing twice, the answer isn't written down anywhere, and that's a documentation ticket.
What I watch for
The quiet one. No questions in the first two days usually means someone is saving them up, so I go and ask what they're on.
The one who starts refactoring on day two. The code is bad, they're right, and the refactor can wait a month until they know why it's bad. I say that kindly and I mean it. The instinct is a good one, it's just early.