How can I help juniors?

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.

Phew, I'm finally done with all the questions! Here are my final general thoughts:

• You seem like a very capable and empathetic teammate, which I greatly respect. I wish there were more engineers like you. 😊
• That being said, I think you may be falling into a failure mode I've seen many other kind engineers fall into (including myself): Sacrificing too much of yourself to save someone else.
• It's pretty clear to me that this junior engineer is a low performer. While junior engineers do come in with 0 professional experience, they should still come in with solid learning fundamentals and general coding ability. I think there's still a chance this can be overcome, but you should be open to the possibility that it can't.

That being said, here's my recommendation in terms of concrete action items:

• Heavily push them to ask help from others - You are becoming a single point of failure for them and this helps neither of you. Let's say you go out on vacation for 2 weeks - It seems like this junior engineer would be doing literally nothing during that time as they're wholly dependent on you.
• Talk to your manager - They should know about this in general, and from there, they should create clear expectations. First, you should have a concrete understanding of what your manager expects from you. Second, you should create a plan with well-defined milestones for this junior engineer.
• Time-box your involvement - From #7 and #8, it seems like this is grinding you down, which I totally get. I would limit your involvement to just 30 minutes a day tops. Maybe even reduce it down to just Monday/Wednesday/Friday. You can make it official by booking a recurring meeting at the beginning of each day - This will push the mentee to come into those meetings prepared with sharper questions and more "homework" done to extract maximum value from your teaching. Right now, they are likely used to you doing almost everything for them, which is leading to, well, everything you described in the original post.

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 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. "What have you tried so far?"
2. "Have you tried making some changes to the code and seeing what happened?"
3. "Which parts of this codebase seem the most important to you?"

#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:

1. You aren't explaining it well - I don't believe this is the case given how well spoken you are.
2. There is a bad fit between your explanation style and how they learn - This can be solved by referring them to other resources to learn the concept (e.g. YouTube videos, Udemy course) or trying to have another teammate explain.
3. The other person is bad at learning - This one is the hardest to resolve. In this case, more tough love is probably needed, and you need to push them harder to think things through. As mentioned before, put the ball in their court by countering their questions with questions of your own. Force their brain juices to really start flowing.

How can I be sure what are they suppose to know and what's not?

This one is pretty straightforward:

1. They should know everything that's required for them to ship their tasks on time.
2. They should be showing behaviors that match expectations for their level within your organization/company. If your company is on the larger side, you should have a career rubric. To figure it out via people, you can talk to your manager and also compare this junior engineer to other junior engineers on the team.

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

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:

• [Case Study] Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta
• "How do you enable seamless onboarding of a new engineer or intern into your team?"
• "How to help an underperforming team member?"

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!

• Asking Effective Questions That Get Great Answers Quickly
• Bad Question vs. Good Question Example
• "How do you overcome the fear of asking stupid questions / bothering people when you need help?"

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 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 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 ) after reading them but I think the time and the experience will help me since I have the fundamentals now.