The one about mentoring junior developers

In the last few months I have been looking for a new job as a software developer and during the hiring process I have been asked a few times what is my approach to mentoring a junior developer. In this post I intend to give an extended answer of the one I gave to my interviewers.

---

My approach to mentor someone usually starts during the onboarding process, where I help them getting the project up and running, I tell them about all the processes we have and where to find the documentation, and how things are usually done in the company and the team.

This part usually is overwhelming for any newcomer, junior or not, so I try to take it easy and schedule dedicated sessions to cover some of the topics previously mentioned.

The first few weeks, we work together in pair programming sessions, where initially I am the driver and the other person is the navigator. That is, they will learn by watching. Exactly the opposite proposed by Strong-style pairing.

Image taken from this post.

The reason behind that approach is that, in my experience, is quite complex for a junior developer to know at the very beginning where to find most things, so I aim to avoid micro-management, giving instructions all the time about what to do and how to do it.

During that time, I like to explain the basics and show them my approach writing code, putting special emphasis on following best practices to create clean and maintainable code. Besides, I want them to understand why we must write tests, because I know it is something most people struggle with the first time, and the importance of being consistent in everything we do as a team.

I encourage them to ask anything they do not understand and especially to suggest anything they can think of, even if they are not sure whether it makes sense or not. Sometimes really good ideas have been born that way.

We pair a few hours per day, never the whole working day, allowing them to complete their onboarding, take a break or do whatever they need to do.

Of course, we switch roles as the sessions go by, until we find the right balance between both roles in every session. That helps them to refresh, to not get bored, and to practice both ways of thinking. That is, they will learn by doing as well.

Once the junior developer becomes the driver in a session, I do not immediately point out any error or upcoming obstacle, because I want them to learn how to figure things out by themselves.

Besides pairing sessions, I also explain how to make a code review, how to QA the tasks of the rest of the team (especially when there is no QA team) and how to make deployments to production. As we usually are a cross-functional team, I tell them who is the go-to person depending on the needs.

Throughout those first few weeks, more often than not, we have live code review sessions where we review together the code we just created, in case we missed something, or review the code of any other teammate, so they know what they should focus on. Such sessions have always proved very useful.

I must confess that I used to nitpick any minor style offense that I found but at some point I realized that by doing that I was wasting both my time and the mentoree's, when that is something that can easily do a linter. The latest person I have mentored so far once told me that she initially felt that she was not doing anything right, but fortunately she never gave up and kept improving. But not everybody is the same, so the takeaway is, do not nitpick and do not micromanage because the person could feel overwhelmed and maybe could be afraid of making a mistake.

Hopefully, at some point, they will feel comfortable enough to work on their own, so our pair programming sessions are shorter and less frequent. They will start creating their first pull requests and will start reviewing the code of the rest of the team without supervision. They will even start deploying to production.

With that approach, a junior developer could be almost completely autonomous in a matter of weeks or a few months, depending on the person.

Last but not least, I also encourage them to ask for help whenever they need it. Not asking for help is one of the mistakes many of us make at one time or another.

---

Pairing has a lot of benefits for junior developers, because it is an opportunity to learn relatively quickly from a more experienced member of the team.

I think there is not one right way to mentor somebody, but what I have told has worked very well for some people in the past.

Thank you for reading and see you in the next one!