Skip to content
Muhammet Şafak
tr
Asked by: Volkan Answered:

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


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.

Answer

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. 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

Comments

Sign in with your GitHub account to join the discussion. Comments are stored in GitHub Discussions.

More Questions

All questions

Search the site

Start typing to search posts, projects and pages.

Esc to close Powered by Pagefind