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.
1. A mentorship is a two way street. How much time you spend on it is a negotiation between how much the mentee wants and needs, and how much you, as the mentor, is able and willing to give. As a mentor, how much time you spend will also depend upon the relationship you have with your mentee outside of the mentorship; ie. is the mentee on your team? Are they new to the company/org/team? Are y'all working on the same project? Is your success, and the success of your project dependent on this mentorship being successful? Or is this a traditional mentorship, where the mentee is outside your immediate sphere, and you are purely helping them with their specific career goals.
2. Your role as a mentor does not have to be about giving away all the answers and explanations, but to facilitate your mentee's ability to make progress on their own (ie. the classic 'teach them to fish' principle). For example, if they are are asking you generic questions that can answered via a google search, or some internal wiki, then ask them to use those resources, before approaching you with questions. Or help them determine a reasonable amount of time (few hours, perhaps a day) that they should spend independently trying to unblock themselves, before reaching out to you/others for help, and conversely, when to absolutely get some help, whether you are available or not.
3. In most cases, it does not matter to what pre-existing gaps someone has, whether those gaps should exist or not, whether they have previous experience, as long as the mentee is able able to learn, make progress, and fill those gaps. Some people need more support than others, so do give them some benefit of doubt. But if you are not seeing evidence of learning/improvement, then that's a concern, and a signal to evaluate if the mentorship is working or not. I acknowledge that this is an inexact science and not always easy to know for sure.
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 on 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.
For a junior engineer though, I imagine their performance is largely measured with their code output and quality. Here's a thread on metrics you can use to gauge that.
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 around how to 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. It's 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 anserwing on all the questions in such great details! I hoped for at least few of them but you are in a different level :D Rockstar!
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 evetything you said. Thanks to you and Rama this question has turned into a guideline. Of course I have more questions (can you believe that :D) after reading them but I think the time and the experience will help me since I have the fundamentals now.