Day 1 vs Day 90: What a New Engineer Should Actually Be Able to Do
By Fahad Ijaz · · 6 min read
Most engineering managers describe new-hire productivity in feelings: 'they're ramping up nicely', 'still finding their feet', 'starting to contribute'. Useful for a vibes check. Useless for spotting an onboarding plan that isn't working until month four. The benchmark below replaces feelings with specific, observable milestones.
Day 1: Logged In
Hardware works. Accounts work. Repository cloned. Dev environment runs locally. Slack channels joined. This is table stakes and most companies handle it well. The trap is mistaking 'set up' for 'onboarded'.
Day 30: One PR Merged, One System Understood
The new engineer has shipped at least one merged PR (any size). They can draw a rough box-and-arrow diagram of one core system end-to-end without help. They've been on-call (or shadowed someone on-call) at least once. If any of these are missing at day 30, the onboarding plan needs an honest review.
Day 60: Independent on a Small Feature
The new engineer has been assigned a small feature and shipped it without their onboarding buddy holding the pen. They've reviewed someone else's PR with substantive feedback. They've answered at least one question in a team channel that wasn't directed at them. This is the inflection point: passive consumer of context to active contributor.
Day 90: Trusted on Something That Matters
The new engineer owns a non-trivial feature or system. They participate in technical design discussions as a peer, not an observer. A teammate asks them a question instead of an established engineer at least once a week. If you're not seeing this at 90 days, something in the plan is broken: usually access to context, not the engineer.
The Failure Mode Nobody Names
The most common onboarding failure isn't a slow ramp. It's a plateau at day 45 where the engineer can ship small PRs but can't answer 'why did we build it this way' for any system they touch. They become forever-junior on this codebase, regardless of seniority elsewhere. The cause is almost always that they've never been able to explore the codebase on their own terms, only through the bottleneck of senior engineers' calendars.