# How do I mentor a junior without just doing the work for them?

> Kill the reflex to grab the keyboard; your metric isn't how fast you ship today but whether the junior needs you a little less each week.

- Asked: 2026-09-17
- Answered: 2026-09-22
- Asked by: Volkan
- Tags: kariyer, liderlik
- Source: https://muhammetsafak.com/just-ask/mentor-junior-without-doing-their-work/
- Language: en-US
- Author: Muhammet Şafak

---
**Question:** A new-grad developer joined my team and I'm responsible for mentoring them. My intentions are good, but every time they get stuck I reflexively take over the keyboard and solve the problem myself—because we move faster that way and the deadlines are tight.

Then I notice they make the same mistake again the next day, because they didn't find the solution themselves, they just watched me. How do I actually mentor them without doing the work for them? I'm looking for concrete behavioral advice.


Short answer: the reflex to grab the keyboard is precisely the thing you need to kill.

## Short answer

A mentor's job isn't to speed up today; it's to [make the junior productive without you](/blog/mentorship-and-knowledge-sharing-growing-by-helping-others-grow/). So your metric shouldn't be "how fast did I ship" but "do they need me a little less each week?"

## What to do

1. **Take your hands off the keyboard — literally.** Sit on your hands if you have to and let them drive. The discomfort of silence is the price of learning. Every time you take over, you teach them "you'll rescue me anyway".

2. **Ask, don't tell.** "What have you tried? What do you expect this line to do? Where do you think it breaks?" Socratic questions build a debugging model; a ready-made answer just transfers one fact that evaporates by tomorrow.

3. **Timebox the struggle.** Productive struggle has a limit. Agree up front: "if you're stuck for 30 minutes, ping me." Too short breeds frustration and learned helplessness; too long wastes the day. Calibrate that threshold per person.

4. **Let them make reversible mistakes.** If it isn't going to prod and isn't destructive, let the wrong approach play out — the lesson from a mistake they made themselves sticks far harder than advice they watched you give. Reserve hard intervention for irreversible or unsafe things.

5. **Pair on the how-to-think, not the what-to-type.** In the moments you do take the keyboard, narrate your reasoning: how you read a stack trace, how you form a hypothesis, why you check X first. That's the transferable skill — not the code itself.

6. **Praise the process, move nitpicks to async.** Acknowledge good reasoning, not just working code. Push the small nitpicks to PR review so they get uninterrupted flow to actually try. Constantly looking over their shoulder grows anxiety, not learning.

7. **Make it safe to say "I don't know".** A junior who hides that they're stuck can't learn. Share your own mistakes and gaps openly; saying "honestly, I look this up in the docs every time too" removes the pressure to appear flawless. Psychological safety is the ground the whole thing is built on.

8. **Set a visible progress anchor.** Hold a short 15–20 minute weekly 1:1: "what did you learn this week, where did you get stuck, what do you want to try solo next week?" That gives both of you a concrete measure of growing independence and shifts ownership of learning onto them.

**Bottom line:** personally I'd measure myself with a single question: "Do they need me less this week than last?" You'll be slower in the short term — but that temporary slowdown is exactly the point of mentoring. Every day you win by taking over leaves behind someone dependent on the team; every day you're patient grows an independent engineer.

## Related Reading

- [Mentorship and knowledge sharing: growing by helping others grow](/blog/mentorship-and-knowledge-sharing-growing-by-helping-others-grow/) — Blog
- [How does the nature of the work change on the jump from senior to staff?](https://muhammetsafak.com/just-ask/how-does-the-nature-of-the-work-change-on-the-jump/) — Just Ask
- [How do I demonstrate the broader impact expected when moving from mid-level to senior?](https://muhammetsafak.com/just-ask/how-do-i-demonstrate-the-broader-impact-expected-when-moving-from/) — Just Ask
- [Does my channel buffer size choice hide backpressure problems, and how do I decide it?](https://muhammetsafak.com/just-ask/channel-buffer-size-choice-hide-backpressure-problems-decide/) — Just Ask