How to mentor software engineers

I’ve found that these conversations fall into three broad categories, ranging from the strategic to the tactical:

• Goals - figuring out what they really want
• Situations - handling the unfamiliar or difficult
• Skills - getting promoted

In all three areas, I think that radical candor – caring personally while challenging directly – is essential to effective mentoring. You have to have someone’s best interest in mind and you have to be willing to help them see uncomfortable truths. If that’s not in your personality or you don’t feel that way towards a prospective mentee, then please send them elsewhere

To help someone understand their goals, ask questions that help them reflect on their current situation, consider potential futures, and chart a course from one to another.

In the simplest form, it’s the “where do you see yourself in five years?" question, but that’s a big leap for most people. Instead, probe for how well they understand their current situation . What’s going well? What’s not going well? What about your role do you enjoy the most? What’s most frustrating? If you could change one thing, what would it be and why?

Faced with the question “what should I do?" , tell a personal story instead.

First, sharing a related experience reassures a mentee that they’re not alone. Second, they engage the listener’s brain, helping them focus more completely on what they’re being told rather than their own problems. Third, they let a mentee consider a situation through an abstraction – to enable them to see more objectively and consider different perspectives. A story is a teaching tool but you leave the decisions up to them.

Let them take the lead without being prescriptive. You can still be sounding board for their ideas and help them wargame an approach to what they’re dealing with. Even without a story to guide them, having someone in their corner is valuable support.

First, you have to observe the mentee’s activities or output. For coding skills, code review or pair programming would work. For communication skills, sit it on a meeting they expect to actively participate in or watch them practice a presentation. For technical writing, read what they’ve written.

The most important thing you can do is provide actionable feedback . This means being specific about your observations of their work. It also means providing direction about what they could have done differently or what they need to learn or practice in order to improve.

Sometimes, you see someone that you think has potential, but they’re not where they ought to be and they aren’t seeking advice. You could approach them – tell them you think they have potential and offer to mentor them.

If your company has a formal mentoring program, you could sign up. If they don’t, you could invite people to come to you. That doesn’t have to be a formal declaration “hey, if anyone wants to work with me as a mentor, let me know ”. It could be as simple as announcing office hours for anyone who wants to talk and seeing what happens.

There’s one take away I’d like you to have: mentoring is about listening. Resist the temptation to offer unsolicited advice. Listen to what they’re asking about. Goals? Situations? Or skills? Then listen (or observe) before sharing your questions, stories, or feedback.

If you’ve read this far, you may realize that nothing I’ve said is specific to software engineering. Mentoring is a general skill; your experience makes it industry-specific.