Advice for First-Time Mentors in Software Engineering

Let’s say there’s a new software engineer in your team. Maybe it’s an intern or a new hire. Either way, you’ve been assigned as their mentor or onboarding buddy. How do you proceed?

If you’re like many first-time mentors, then you might spend a lot of time answering any questions they have. Or you frequently help them solve problems, making sure they are never stuck. Maybe you also ensure they always apply the best possible solution. Your intentions are good and you want this person to succeed. Surely, all this effort will facilitate that.

Yet, after a few weeks the mentee seems to have become dependent on you. They might have improved a bit, but for some reason, they don’t seem able to answer most of their own questions. You wish they were more autonomous, and would take more initiative, but for some reason they don’t. What happened? You spent a lot of time helping them. Shouldn’t they have learned a bunch already?

Mentoring is not just about answering questions, providing solutions, or getting people unstuck. It’s an opportunity to help empower someone to make their own decisions, and to understand what kind of decisions are aligned with the team or the organisation. Once they have that kind of understanding, they will be more productive, as they will be making less mistakes, and will think more independently. However, getting there may require you to do some things that aren’t intuitive to you initially.

Let’s make it a bit more concrete with an example of pair programming, which can be a powerful tool for mentoring, if done right.

A bad way to go about it, would be to have the mentor dominate the session, by programming a large part of it, and being very specific in their feedback while the mentee is coding, essentially programming by proxy. The solution might be good, but the mentee likely didn’t learn much. It’s like being taught by a teacher that just read their notes instead of engaging the class.

A better way would be to have the mentee code the majority of the time, and ask them questions to check for understanding. Refrain from providing solutions, and try to help them get unstuck by using coaching techniques such as GROW. Occasionally, stop the coding, and ask them what they think will happen before they execute the piece of code they just wrote. Now, they actively have to think and make decisions. This allows them understand the problem better, and also allows them to figure out their specific strengths instead of mindlessly following your solutions.

The same patterns apply to other areas as well. Do they know why a certain ticket is prioritised? Why is it important? What are some of the solutions they would come up with? Do they understand the interactions between applications? What’s the risk associated with deploying a certain service to production?

Allow the mentee to gradually make more and more decisions on their own. Leave some space for them to make mistakes. This might be counterintuitive, but if you are always there to prevent them from making any mistakes, then you are robbing them from opportunities to learn. Think back of some of the mistakes you’ve made in the past. They probably weren’t the end of the world, but I bet they helped you learn.

Don’t underestimate the mentee, check with what they are comfortable with, and give them tasks that are slightly outside of their comfort zone. Be there to support them, but don’t be overly protective and define clear expectations for them that focus on the outcome, not the way they get there.

Answering questions and sharing your expertise helps, but try to put a limit on it and learn coaching techniques instead of answering directly. If you’re just providing solutions all the time, you risk the dependency issue we talked about in the beginning.

Apply these concepts, and you’ll see that they’ll become more autonomous, more quickly.