How does mentoring work? I asked this question ten years into my software engineering career when I joined Uber. Until then, I've never received or done mentoring, or at least never put this label on any activity I've done before.

Uber, however, had an official mentoring program. Almost every engineer I met had a mentor. Mentorship is an expectation for senior and above engineers, it being listed in our engineering competencies. Since working here, I've been mentored, been a mentor, and have observed engineers around me grow via mentorship.

Mentorship has been the best things that's sped up my growth and others engineers around me. This post discusses mentorship practices that work well engineer-to-engineer. Topics on informal and formal mentorship, tips for mentees and mentors and touch on remote mentorship. The practices come from my own experience, observations I've made people mentoring each other and from conversations I've had with half a dozen mentors in my network and on Coding Coach. I'm hoping this post will be a good starting point if you're either an engineer wanting to mentor, or a developer looking for mentorship. Let's dive into the topics:

• What is mentoring?
• Onboarding: a specific type of mentoring
• Informal mentorship: it's happening everywhere
• Formal mentorship: more effort, more focus, more growth
  • Kicking off mentoring: the introductory meeting
  • When you are a mentee
  • When you are a mentor
• Being a supportive and efficient mentor
• Remote mentorship
• The best engineers are great mentors

What is mentoring?

I've heard the term mentoring used with various meanings, often as a substitute for onboarding, coaching or helping. I like to narrow this down. In my take, mentorship is a learning relationship between an experienced person and someone who wants to grow. The Wikipedia definition of mentorship is not far off. The person receiving mentorship is referred to as the mentee, while the person sharing their expertise is the mentor. With software engineering, the setup is pretty typical: a more senior engineer mentors a more junior person.

Reflecting on my previous experience, before joining Uber, I do recall many situations where I was mentored or was a mentor. When I was a junior developer, I paired with a senior engineer for a few months, learning lots from him. When a new person joined our team, I sat with them for a few weeks, helping them understand the codebase. These were all mentoring situations, though I never put the mentorship label on them.

Onboarding: a specific type of mentoring

A common type of mentoring is having an onboarding buddy when joining a new company. This person helps understand the new environment, and often pairs to write code that ships to production for the first time. They explain how systems, processes, and unwritten rules work. Some teams refer to this role as a mentor as well.

I find onboarding being a nice example of mentoring. It's well-defined in scope: the mentor shares their expertise on how the team and company work. The duration is not too long and not too short: it lasts from the first day to when the new start is onboarded, typically in one or two months. Also, the responsibilities are clear: the mentor needs to do a lot of the preparation and drive this relationship, given the mentee is new. It's also something that happens pretty frequently. Most engineers are receivers of this mentorship every time they switch companies - even if it's not formalized.

Informal mentorship: it's happening everywhere

Mentorship doesn't need to be formal for a less experienced person to learn from a more experienced one. And for the most part, it isn't. It happens naturally when developers work together and collaborate.

Code reviews are frequent examples of informal mentorship. There's no need for formalities for a less experienced person to learn from a more experienced one. And for the most part, there are no formalities. At teams and companies, where code reviews are everyday practice, this learning happens with every review. It happens with good code reviews and even more with better code reviews. Code reviews and the discussions during and after helped me significantly level up as a developer. I had many mentors, learning a little from each of them.

Working on a project, as part of a team is another situation where mentorship is given and received. It might be during planning meetings, architecture discussions, whiteboarding, retrospectives, or something else. When working closely with other developers, feedback and learning naturally happen.

Formal mentorship: more effort, more focus, more growth

The mentoring I've observed to be rare for developers is a more "formal" type of mentorship. A setup where a more experienced mentor agrees to mentor a more junior engineer, they kick things off and have a regular cadence of meeting and the mentor helping the mentee grow.

Why bother with the effort of more formal mentorship? After all, informal mentoring happens all the time. Well, first, you might not be working with enough experienced people and would want to find someone targeted to learn more from. Second, more importantly, having a more "formal" mentoring relationship can help you grow faster and in a more focused way.

There are two places where it's easy to get started with more formal, more focused mentorship: at more structured tech companies and within online communities. More and more tech companies have internal mentorship programs. Unfortunately, though, they advertise very little of these to the outside world. Uber, PayPal, and Amazon all places I know have various internal programs that make it easy to get more focused mentorship. Online communities of mentors are also a welcoming place with an easy way to start. Coding Coach is a new and thriving online community, which is a great place to join as someone looking for mentorship or as a mentor.

Having formal mentors throughout my developer years would have helped me grow faster. So when I transitioned into engineering management, my first point of action was finding a mentor. This decision was the thing that helped me grow the most. I've seen similar success stories with developers on my team after they kicked off focused mentoring with another engineer. For junior engineers, it was no surprise that they ended up growing faster. What I did not expect is how much senior engineers gained from setting up formal mentorships with more experienced - staff or principal - engineers.

So how do you go about setting up formal mentorship? Like with any long-running project, a good kickoff helps to get all participants - in this case, the mentor and mentee - get on the same page.

Kicking off mentoring: the introductory meeting

The best way to start formal mentorship is with a kickoff. I often suggest people to approach potential mentors and open along the lines of "You're someone I look up to. Can I setup time to talk about areas I'd like to grow in and how you could potentially help, as a mentor?" It's good to get some dedicated time for this, to share some background and see if both people can and do want to commit time for mentoring.

Come prepared for the intro, making a list of the topics to discuss. Here are a list of ideas that are worth discussing on this kickoff.

Don't forget; it's always okay to say no to mentoring. As a mentee looking for a mentor, I've had potential mentors politely decline several times. Sometimes it was lack of time; other times, they felt they did not have the expertise I was looking for. Don't let this derail you: ask for any other recommendations this person might have and try meeting another potential mentor. Sooner, rather than later, you'll have your first match.

When you are a mentee

With a running cadence and regular catch-ups in place, how do you keep getting value out of the mentorship? I'm a firm believer that as a mentee, you need to invest time and effort in mentorship, to get value out of it. Set expectations clear from the start. Come prepared to the catch-ups with your mentor, making good use of their time. Bring challenges, wins, and areas you'd like to get their input on. Have a list of top things you'd like to talk through with them. During the discussion, as you get advice and ideas, commit to actions, follow through with these, and let your mentor know how it went.

I like to keep a running doc, shared with my mentor, where I drop notes between our catch-ups and prepare a list of topics. The structure I use is this:

• Key things that happened since last time. I like to fill in mentor briefly on key things that happened since last time. I keep this short.
• Reflecting on action items / guidance / discussions from last time. If I did something we talked about last time like tried out an approach, read a book, I share the results. This is useful for both of us, and my mentor gets to learn something interesting.
• A challenge I'm having, talking through it and brainstorming on an approach to solve it.
• A recent success I've had. I describe a situation I thought I handled well and why I thought it went well, asking my mentor to share what she thought of it. Nine out of ten times, I get feedback from a different angle, that make me re-evaluate how I'll handle the situation the next time.

When you are a mentor

Being clear with expectations both ways is the foundation for a good relationship. Clarify how much time you can commit to, and also tell your mentee what you're expecting from them. If you'd like them to come with a list of things to talk through, say so. If that's not your style and keep it casual, tackling things as they come, discuss this upfront as well.

Being a supportive and efficient mentor

Being an efficient mentor is not about solving other people's problems. It's about helping them grow so they can solve their problems themselves. When mentoring, you want to delay sharing solutions as long as possible.

Listen to what your mentee has to say. This is the most important role a mentor can play. The mentee is coming for advice, but talking about what's going on and how they are feeling is just as important. Try starting the conversation with questions that help you listen, like "What's on your mind?", "What are you struggling with?", "What are you working on?", "What are your goals for the week?". Sit back, listen and think about areas you might be able to help with.

Discuss specific situations to dive deeper. These situations can be ones brought up by the mentee or ones noticed by the mentor. Topics can be from communication, cultural issues, deep technical questions, code reviews, and many more.

Provide context and perspective for the specific situation. You probably have been in the industry for longer and had similar situations that your mentee is struggling with. If you work at the same company, you probably know how things work a lot better. Reflecting on how you experienced a similarly challenging situation back in the day, and how you also struggled with it can help the mentee feel less anxious.

Leverage your network to help your mentee. This is especially powerful when you work at the same company, as you can put them in touch with other people who can help. Mentors are usually a lot better connected than mentees. Making introductions and asking others to spend some time with the mentee goes a long way. When you don't work at the same company, you might still see opportunities to connect them with others, helping with a warm introduction.

Be supportive and let them know that you are on their side. People who approach you for mentorship are not only looking for advice but also support. The less experience they have in the field, the more likely they feel like an impostor and the more your support will help them. Encouraging words go a lot further than you would think:

Any mentor I've worked with here so far has always ended our conversations with -- "You got this" or "You can do this" or something of that nature. They may just be words, but damn if they don't mean the world to me. (quote from a mentee sharing their experience)

Avoid giving answers on a silver plate. You want the person you're mentoring to get to solve their problems themselves, with as little direct guidance from you, as possible. Ask questions, offer alternatives, and hold back telling people what to do. Taking a patient, coaching-first approach empowers more junior developers and accelerates their learning.

A few more tips on how to be a great mentor:

• Aim to learn something new from your mentee. Be curious about the problem they want to solve and understand their viewpoint. Even if you know a good answer, if you coach them down the line, you might learn something new, looking at the problem through a different lens.
• Help mentees come up with multiple solutions to their problems and help them articulate the tradeoffs themselves. Explain concepts over solutions and help mentees understand that there are rarely black or white answers. This is especially true for technical topics and mostly holds for non-technical problems.
• Tailor your approach for technical vs non-technical topics. Technical questions are usually easier to deal with: you can coach by asking what avenues they've tried and guide them with questions towards something that works. For non-technical topics like communication, conflict and others, listening is key.
• Mentoring brings benefits on the long-term as well. Beyond the short-term benefits of becoming a better communicator and teacher, don't forget about the long game. The software industry is small, and the person you are mentoring as a junior soon grow more senior. In a few years, they might be a director or CTO even. Be a supportive mentor, and they'll think fondly of you. You might reconnect later, in a different setting.
• There is no one pattern for mentorship. For most people, mentoring is a mix of informal mentorship and regular catch-ups. People often reach out to mentors with one-off questions. Some prefer in-person mentoring, and some mentorships don't go beyond reviewing code. All the mentors I've talked shared one thing about what their approach is: "It depends."

Remote mentorship

Mentoring is powerful when done in-person, but sometimes mentors are not based in the same place or location. Mentorship is a powerful tool with this setup, as well.

One of my mentors lives in San Francisco, so we do video calls all the time. I've also talked with several experienced mentors who do remote mentoring on Coding Coach and have all had great experiences using this format.

Exercises work exceptionally well for remote technical mentorship in this kind of relationship. Both mentors and mentees have mentioned that this is a tool that they've seen work better than others. A mentee I talked with, summarized it like this:

I personally enjoy getting my hands dirty, so when my mentors have offered up exercises, or specific challenging questions that require me to figure it out, I loved it. The information seems to stick more. (quote from Ryan )

The same rings true from the side of the mentors. As an experienced mentor says:

When mentoring remotely, I try to help by giving some exercises regarding the level of the developer. I do the exercise as well and I give several steps to build, but I give no indications/hints at the beginning. There is just a problem that needs to be solved. I'm doing this, since a big part of the developer's job is to know what and how to search. So the mentee is usually spending a lot of time looking for online examples or pieces of algorithms they have to understand eventually. When they are ready, we talk about our mutual solutions, and I ask to explain the choices they've made. We discuss the algorithm, the methods they chose, and the code quality. (quote from Loïck)

The best engineers are great mentors

The most sought-after software engineers I know, are all generous mentors. People not only look up to them for their coding, architecture, and execution skills. They also do so because they are approachable and continuously help others grow around them. This is because they are generous mentors, may this be informal or formal mentorship. And mentorship is how they keep growing their skills in areas like teaching, listening, and leadership, and growing a strong and supportive network around them.

If you are not being mentored or mentoring, reach out and find a mentor, or volunteer to be one in your company or online. Doing so will help yourself and other people grow further.

A slightly extended version of this post was originally published on my blog. That post includes the additional sections Mentorship across the organization and additional quotes from mentors who are devlopers.

About me: I'm an engineer turned engineering manager, working at the intersection of Silicon Valley & European startups and tech companies. Follow me here and on Twitter. I write longer essays on software engineering on my blog, The Pragmatic Engineer. I also send a monthly newsletter with extended notes on software engineering and tech leadership topics.