I am mentoring juniors for the last few weeks. In the past, I've been mentoring people with some professional experience but this colleague doesn't have any. Now, after these few weeks I am wondering:
I think the colleagues are really motivated and this is one of the reasons I want to help them. I want to be sure I did everything I can.
That's a lot of good detailed questions! I may not be able to answer all of them, but I'll make a few general points, that I hope will be helpful to you in assessing your particular situation.
Thank you Rama for your detailed answers!
I will give more clearification on 1. - Your questions makes sense. Some of the juniors are working with other teams (I spend less time and it is fine), some of them with me on project I am resposible for (I spend sometimes 2-3h). They are new to the company (work here for a month). No special relationship with anyone of them. They have just started and are all "equal" :) for now.
Thank you for your detailed explanation on 2 and 3!
Thanks for sharing such well-written and detailed questions! My immediate reaction is that this junior engineer is lacking some fundamental skills, so I highly recommend this discussion: "How to ramp up a slow learner?"
I also recommend these resources:
Now I'll go through all the questions 😊
How much time should I spend helping them? Currently, I have to spend 2-3 hours for person per day otherwise they will be blocked for days.
There isn't a hard number, but I can firmly say that this is too much. That's up to 1/3 of your total time, which is absolutely massive.
I have mentored very fresh junior engineers before, and I generally got them to a time investment of 2-3 hours per week rather quickly. Even in the first few weeks, I spent an average of 1 to 1.5 hours per day, which is half of what you're doing now.
Even though I am trying to explain that they can ask other colleagues as well, they are not asking anyone else.
You have the right idea, now you just need to enforce it. You can be polite about it: "Hey, I really want to help you and appreciate your questions, but I'm just too busy right now. Can you ping teammate X and see if they can help?" Ideally you talk with teammate X beforehand and let them know that this junior engineer may be going their way.
How can I be sure what are they suppose to know and what's not?
This one is pretty straightforward:
How can I measure properly their performance since they are just starting? What is a normal performance?
You might want to work with your manager to create an onboarding doc for them: "What should be part of an Onboarding doc?"
For a junior engineer though, I imagine their performance is largely measured with their code output and quality. Here's a good resources on the metrics you can use to gauge this: "Internship Metrics For Conversion?"
If I were to throw a number out there, a solid junior engineer should be landing 2-5 commits per week. However, I don't know what company you're in, so I'm unsure how well this fits. If you're at a hypergrowth startup, 2-5 feels low, and if you're at a more mature, older company, 2-5 could be too high. I have seen both of those be true.
How deep should I go in explanation of his questions?
As a mentor, you should always be thinking "How did I come up with the answer I'm giving, and can I share that methodology alongside my answer?" As Rama mentioned, your goal is to teach them how to fish, otherwise this mentee could be dependent on you forever. I also recommend this discussion: "How do you answer questions effectively?"
I believe this is where the high quality questions will help them, but I believe they have a lot of gaps to make a quality question and give the proper context.
There are a lot of free Taro resources you can share with them to help there!
How can I help them to improve their questions instead of having to explain for hours one topic and then another, etc?
On top of the prior resources I linked, I recommend getting into the habit of responding to their questions with a question of your own.
Let's say they ask a question about how to understand and modify a certain part of a codebase, which is the classic junior engineer question. You can ask them:
#1 in particular is the most relevant and standard one. If they have tried nothing, ask them why. Were they too scared to make a change? Is their IDE having some problem? Do they have 0 idea where the relevant code for their task is to begin with?
When should I say I give up on him? I really want to try everything before giving up.
Good question, and I feel the same way when it comes to mentoring people. 😊
The answer is a combination of this mentorship holding back your own contribution and learning progress being near non-existent.
From your post, I'm guessing you are a senior engineer or higher. This means that your expectations are going to be pretty high, and I really don't think it's possible to meet senior engineer expectations while spending 2-3 hours per day hand-holding a teammate. Stay in sync with your manager and make sure that you're doing okay as well as we talk about in-depth here: [Masterclass] How To Navigate Your Performance Review In Tech
In the end, it's simply counterproductive for a team to sacrifice a senior engineer to save a struggling junior engineer.
Work backwards from what you need to do to meet your own expectations and use that to inform your support. If you work 8 hours a day and need 7.5 hours to get your own stuff done, allocate 30 minutes max to this mentee.
On the learning front, it should be apparent, even for a junior engineer. You should see an increased sharpness to their questions. They should be landing more commits per week. Their code quality should increase and have less back-and-forth on the code review. If none of these are apparent after 1 month (or even 2-3 weeks), this junior engineer is probably a low performer that can't be rescued.
How to stay less emotional when explaining the same things for hours to the same person?
So the frank answer is to not explain the same thing for hours. If it takes more than an hour to explain something, something is probably wrong and one of the following is true:
How can I help them to understand me better? Sometimes, no matter how am I explaining specific case/topic and no matter what examples, nothing helps.
On top of the resources I've linked in prior responses, try flipping the script. Ask them, "What is your current understanding of this topic?"
From there, you can "tweak" whatever mental model they have into the correct one. This feels more effective to me as you're working backwards (starting with what they currently have) instead of working forward (giving your own understanding and hoping that resonates with them).
Phew, I'm finally done with all the questions! Here are my final general thoughts:
That being said, here's my recommendation in terms of concrete action items:
Thank you very much Alex for they time spent answering on all the questions in such great details! I hoped for at least few of them but you are in a different level
Apologize for all these questions under a general one. I had doubts how to approach this. But I decided it will be much easier for me and everyone else who may struggle with that and come to this question at some point in their career.
It took me some time to go deep into everything you said. Thanks to you and Rama this question has turned into a guideline. Of course I have more questions (can you believe that