In 2021, I happened to have chances to mentor some software engineer interns at my work. I mentored 5 interns in total and maximum 3 interns at the same time. This is a great experience to me and to be honest, I also learnt a lot while giving mentorship. So today, I'd like to share some of my ideas about mentoring junior software engineers.
1. Keep Your Mentee Group Size Small
I would admit that, at start, I was quite happy that I could mentor 3 interns at the same time. It was my first official experience practicing mentorship at work, so I was very happy that my capability was recognised by my superior. However, I found that I was too naive. More mentees means greater responsibilities and I would need to spare more time from my work to provide mentorship.
Why do I have to spend much time to mentee? Why not just assign the tasks and wait for results?
I suppose, Mentees usually are not familiar with team culture and norms when they just joined. They need guidance so that they can understand what to do and what not to do. In the beginning, they may not have any question because they would not know what to ask. Only when they actually start to work, will they find out that problems are everywhere. And because I am the mentor, I will be the first person they think of and ask for help. To let mentees be better adapt to work, I need to spend time for explanation and guidance.
I had maximum 3 interns with me at the same time, and they were doing 2 different areas of work, front end development and data warehouse development. While providing guidance to them, I had my own work to do as well. So it ended up that I had to work overtime.
Thus, keeping your mentee size small helps you mentor your mentees better, and put yourself in a more relax mode.
2. Prepare An On-boarding Guide
To minimise your time, you can prepare an on-boarding guide to explain fundamental questions. Probably you need to spend several hours to prepare it, but it's really useful because it can be reused every time!
I did an on-boarding guide and here's what I included in the guide:
- How to setup the development machine, including software needs to install and environment variables to setup. If possible, it's better to also provide a way to verify if the software is correctly installed. There are often strange problems happening. It's better to provide a way of verification so that the mentees can at least check own their own first.
- How to setup the project, including dependency installation, how to run the project and also environment variables to setup. This is definitely a must-do, otherwise, no one can work productively.
- Who to ask if general problems are encountered. New comers are not familiar with the team structure. When some problems happen, the mentor is the first person they think of. However, sometimes the mentor might not know much about some specific topics, and they still need to direct the problem to someone who is more familiar. So why not just specify the people map in the guide? In the guide, you can specify system module owners who is the most familiar with that module, so that your mentee can be self-driven and directly approached the person who is the most knowledgeable to that problem.
- List of video recordings of past technical sharing, tutorials or training. Sometimes we have internal trainings and sharing held, which can be recorded. Those trainings and sharing are often about our own projects or products. Having these links provide better opportunities to mentees to learn about the project by themselves and to mentors to save more time.
- FAQs for quick references on strange problems. No matter how well you prepared, there are always strange issues happening. For example, a weird error message on python project initialization can be caused by a newly created remote development machine having setup issue during the creation. These are unusual problems which happen rarely and cannot be found in the knowledge base. So it's better to record this problem under FAQ session just in case it happens again and investigation time gets wasted.
3. Have Regular 1 on 1 Sessions
Mentors can be very busy on their own stuffs ans sometimes may omit the mentees. The best solution to this issue is to schedule repeated meetings with the mentee on a regular basis. It can be weekly or fortnightly (I do it fortnightly).
A 1 on 1 session can be short, such as 15 minutes, so that it does not create pressures to both sides.
Most importantly, 1 on 1 sessions are not meant for performance evaluation. The latter is too formal and makes people nervous. While the former is more relaxing, it can be just like chit-chatting. The purpose of 1 on 1 session is NOT to judge or evaluate, but to communicate and advise.
There are a few topics I often use during the 1 on 1 session:
- How is it going recently? (A general question to warm up)
- Do you encounter any problem at work?
- Did you solve it, if so, how did you solve it? If not, how can I help so that you can solve it?
- Does the work align with your expectation? If not, what is missing for you?
It's important to let the mentee to speak out, so these questions are all encouraging the mentee to share their thoughts. Probably a mentor is more knowledgeable in certain fields and more experienced, but in this communication, everybody is equal on the same page. In this way, the communication can be helpful and positive, true thoughts can be shared and then real problems can be revealed and fixed.
In the end, mentors can also share about their views, including praising for what mentee have done well, suggesting areas which mentees can improve on. When speaking about improvement parts, it's better to directly point out areas needs improvements with the focus on the fact only, and possibly provide a direction so that the mentee can know how to get improvement started.
In a word, 1 on 1 session is meant to align the expectations between mentors and mentees, find out the problems and solve it, on equal positions with respects.
4. Assign Tasks by Considering Difficulties
While assigning tasks to mentees, mentors need to understand the tasks too. Some tasks may be easy or small, and some tasks can be hard or big. It's important to assign suitable tasks to mentees considering their experiences, capabilities and time.
What I did is that,
- In the beginning, you can assign simple tasks such as logic corrections, simple unit tests, typo corrections which are easy to complete, so that the mentees can be familiar with the work flow and the code base first.
- Gradually, when mentees gets more familiar, you can assign them some small features such as developing a small form, writing a consolidation API, or non-urgent bug fixes. For bug fixes, though mentors are more experiences who can spot out the cause and find solutions right away, mentors should not directly tell the answer to the mentees. Instead, mentors should encourage the mentees to read through the code base and understand the contexts on their own, and finally let the mentees to solve the problems own their own. In this process, advices and hints can be provided at appropriate time, since there are definitely some contexts which are very hard for mentees to figure out on their own (such as lousy logic designs in legacy systems, which nobody knows exactly how it works :x)
- When mentees are ready, you can assign a non-urgent mid-size feature like a small project to them, so that they can start to work independently. You can provide them a rough idea, and let them try to design the feature on their own. You can then review the design and help to improve. After that, mentees can start to independently work by themselves. At this step, the mentee is already at the stage where they are capable to work independently. And I think it will be a good time for mentees to graduate :D
Summary
These are what I learnt from the past one year experience of mentorship. To be honest, as a mentor, I am still quite newbie :) Please leave your comments below to share your thoughts about mentorship so that I could also learn from you. Cheers~!
Top comments (3)
Glad I came across this.
Do you think that mentor and meentee need to be in same team (same project inside a company)? What about giving tasks to them if metor is not i same team, is that possible? What you think?
I think it doesn't matter which team the mentors and mentees are in. What matters is that the mentors and mentees have the same contexts regarding the tasks. As long as the contexts can be aligned, such as task difficulties, task details, mentors can provide necessary guidance when needed by mentees.