You hired a senior developer six weeks ago. They seem smart, ask good questions, and blend well with the team. But something feels off. You can't pinpoint it yet, and frankly, you're second-guessing yourself because everyone says "give them time to ramp up."

Here's the problem: ramp-up empathy can blind you to genuine underperformance. The longer you wait, the more technical debt compounds, the more your team compensates, and the harder the conversation becomes.

So how do you know if you're looking at a slow onboarder or a mis-hire?

1. They ask the same questions multiple times

Good engineers ask clarifying questions. Great engineers document the answers and build mental models.

If your new hire keeps asking "where's the staging environment URL?" or "how do we handle retries again?" after the third week, that's not thoroughness. That's a signal they're not internalizing information or building context.

Warning sign: they're not taking notes, not updating internal docs, not creating their own reference points. They're operating in a perpetual state of handholding.

2. Their pull requests never touch the hard parts

Look at their commit history. Are they only fixing typos, updating constants, or tweaking CSS? Are they avoiding the database layer, the authentication flow, or the core business logic?

Junior developers stick to safe zones while they learn. Senior developers should be progressively moving toward complexity, even if they're moving slowly.

If week six looks identical to week two in terms of problem difficulty, you don't have a ramping issue. You have a capability gap.

3. They can't explain their own code in a review

You're doing a code review. You ask: "Why did you structure it this way?" or "What happens if this API times out?"

If they struggle to articulate trade-offs, or worse, if they seem surprised by the question, that's a red flag. Strong developers think in terms of constraints, failure modes, and alternatives. Weak ones copy patterns without understanding why.

This isn't about being articulate. It's about whether they made deliberate choices or just made it work.

4. The team starts routing around them

Your other engineers stop assigning them tickets. Or they start "checking in" on their work more than usual. Or they quietly refactor the new hire's code after merge.

This is the canary in the coal mine.

Your team knows before you do. They're already compensating, which means they've decided it's faster to do it themselves than to wait or explain. If you're not seeing this explicitly, check Slack threads, PR review patterns, and ticket reassignments.

5. They lean on AI but can't debug when it's wrong

Using AI to accelerate work is smart. Blindly trusting AI output is not.

If your new developer copies GPT-generated code but can't trace through it when it fails, or can't explain why a suggested refactor would break production, they're using AI as a crutch, not a tool.

Strong signal: watch how they handle a bug in AI-generated code. Do they methodically trace it? Or do they throw it back into the AI and hope for better output?

Real engineering is knowing when the machine is wrong.

6. Their commits don't correlate with reported hours

You don't need to micromanage git activity, but patterns matter.

If someone says they spent eight hours debugging a query but there's one commit with a two-line change and no comments, no documentation, and no evidence of exploration, something's off.

Conversely, 47 commits in an hour usually means they're guessing, not problem-solving.

You're not measuring productivity by lines of code. You're measuring intentionality and methodology. Strong engineers leave evidence of their thinking. Weak ones leave chaos or silence.

7. They don't ask about production

By week four, a good engineer is curious about how things run in production. They ask about monitoring, error rates, deployment processes, rollback strategies, on-call rotation.

If your new hire hasn't asked a single question about production behavior, observability, or operational concerns, they're either thinking purely in terms of "make the feature work" or they've never had to own production systems.

That's not a seniority match.

What to do next

If you're seeing one of these, stay alert. If you're seeing three or more, you likely have a performance problem, not a ramp-up issue.

The fix isn't to wait longer. It's to get specific.

Have a direct conversation. Show examples. Set clear expectations with measurable milestones for the next two weeks. If they can't course-correct with explicit feedback, you have your answer.

Most importantly, trust your team. They're living with this person's output every day. If they're routing around the new hire, you're not being paranoid. You're being late.