Guide for mentoring

A few tips I learned along the way for mentoring developers.

Intro

I have had experience mentoring developers within a large corporation as well as people I knew well outside of work who were newcomers to the IT industry. Over the years I have picked up a few rules to mentor by on my own and from my colleagues that really makes it easier for both the mentor and the mentee.

There are different types and goals of mentoring. I am going to focus on mentoring as a part of an onboarding process. Mentoring can be present for interns as well as more experienced developers. Keep in mind that different people require different approaches. Though some things remain fairly consistent from a person to a person and I want to list them below.

Daily sync up

A sync up - a meeting with a fixed start and end time. It helps for both a mentor and a mentee to have some time booked from their schedule to take apart questions and ease the onboarding process. Make sure this meeting is on the calendar for both attendees. This is especially useful in the beginning. After a while the need for this meeting starts to die off. There are three reasons it will be more productive for both:

1. Mentor has a dedicated time frame to help with the questions.
2. If a question is not blocking for a mentee than it is okay to note it down and ask at a more appropriate time.
3. Both have time to prepare for this meeting.

Having these meetings in the evening works great since the questions and context for them is still fresh. 30 minutes is a decent duration for such meetings. Do expect to have a few of these meetings to go overtime specially during the beginning of the mentorship.

Note down the questions

In my experience I usually try to keep a wiki page or a gist with a list of questions that we discuss during the sync up meetings and ask the mentee to fill in the answers after the meetings. This might not seem as useful at first. Yet it can help with multiple things:

• To avoid the repetitive questions from the same mentee.
• If you see a pattern across multiple mentees it is a good chance that you have discovered a gap in project's documentation.
• It is handy to have a backlog of what was discussed over the time of an internship or a probation.

Differentiate blocking and non-blocking questions

This is important. If a mentee has a question it may not be as important to answer it straight away. But context switching for a mentor is usually more expensive. And that is why it is important to make sure that there are two types of questions. I tend to define blocking questions as the ones that do not allow the work to be completed on time and there is nothing else to do which is often not the case.

If a mentee is faced with a blocking question there is no need to go right away to the mentor. It should be expected to try to solve the problem on their own for a brief period of time (15-20 minutes) and if problem is still there than it is okay to proceed to ask the mentor. The reason this is important is that now the question can be phrased in a particular way that can both play a role of a rubber duck and a better context for the question for the mentor i.e. "I have a problem X while doing my task, I have tried Y and Z with no luck". It is rather frequent to discover the answer during the phrasing of a right question.