Hey everyone, Neil here. You're reading High-Signal Hiring. Hiring systems from 20+ years of global recruitment experience and 500+ technical hires. Zero noise and instantly actionable.
Last week I argued the résumé has stopped telling you anything, and that your first filter should be one piece of proof of work instead. That was the top of the funnel.
This week I want to jump to the other end. Past the interviews, past the offer, to the bit most founders file under admin and never think about again.
Onboarding. Or more specifically, how long you reckon it takes a new engineer to become useful, and why that number is probably a few years out of date.
You’ll learn where ramp times have actually landed, what the first month can tell you that six hours of interviews can’t, and what to set up before your next hire starts.
Not a subscriber yet? Sign up here
| Where ramp times have landed
DX published their Q1 report on AI-assisted engineering earlier this year, drawing on data from 400 companies. The average time for a new engineer to reach their tenth pull request came out at 33 days. A quarter earlier it was 39.
The split within that is where it gets useful. At companies where engineers barely touch AI tools, the same milestone took 91 days. At companies where they use it daily, 49. If you’re hiring engineers this quarter, the report is worth your time.
None of this is mysterious once you think about what a new engineer’s first month used to involve. A large chunk of it went on simply working out where everything was and how the pieces fitted together. There was no shortcut for that, you just had to read a lot of code and ask a lot of questions. Now someone can point a model at the repo and get a reasonable explanation of a service the same afternoon. That doesn’t make them productive on its own, but it does remove a bottleneck that used to eat weeks.
| Founders are still working to a three-month clock
Nearly every founder I speak to carries the same rough assumption. A new engineer takes about three months to properly find their feet, so there’s no point drawing conclusions until then.
That was a fair assumption when orientation on its own took the best part of a month. It’s a lot shakier now, and it has a habit of turning into an excuse.
I’ve watched this happen more than once. A founder is five weeks in, quietly worried about someone, and tells themselves it’s too early to say. Meanwhile they’ve had five weeks of evidence sat in front of them that they’ve decided in advance not to read.
| What the first month can actually tell you
You interviewed this person for a handful of hours. They’re about to work for you for a month. That’s a far better look at someone than any interview loop gives you, and most founders waste it because nobody wrote down what good was supposed to look like before day one.
So write it down. Agree a specific piece of work and a date, before they start, and tell them what it is. Something small shipped to production in the first week. Something that matters, owned on their own, by day 30. A real thing that either got done or didn’t.
Then when the date comes round you’ve got something concrete to look at. If they hit it, you know they can operate inside your setup and you can stop wondering. If they missed it, you’ve got a much better question on your hands than “is this working out?”. You get to ask why. It might be them. It might just as easily be that your codebase is harder to get into than you think, or that nobody ever gave them enough context to make a call on their own. Two of those you’d want to know about regardless of who you’d hired
Founders who leave this conversation until month three have usually made their mind up long before. They’re waiting for a date that gives them permission to say it out loud.
| A word of caution before you start counting
Someone can get to ten pull requests in three weeks and still be wrong for the job.
Moving through a codebase quickly shows you they can handle your systems, your review process and your people without getting stuck. Whether they’re pointed at the right problems is a separate question, and AI tooling has made it much easier to produce a pile of reasonable-looking work in a direction nobody asked for.
Which is why I’d look hard at one thing they owned end to end rather than at the count. Ownership forces the judgement calls that volume lets someone dodge. If what impresses you is mainly how much appeared, that’s the same mistake as being impressed by a polished résumé, just further along the process.
| What to set up before your next start date
Agree the day-30 piece of work with them before they accept the offer. It’s a fair thing to ask, and in my experience the good ones react well to it, because it tells them you know what you actually want from the role. (The ones who bristle at it are giving you information too.)
Put the day-30 review in the calendar now, with that work as the agenda rather than a general chat about how they’re settling in.
And if two hires in a row miss the same mark, look at your onboarding before you start questioning your interviewing. It’s cheaper to fix and it’s more often the culprit.
You’ll learn more about someone in their first month than in every interview you ran. Whether that’s any use depends entirely on what you decided to look for before they walked in.
Cheers
Neil