Ask HN: Any Tips on Mentoring an Intern?
7 comments
The number one advice i can give you is;
1) Do NOT kill their Motivation, Enthusiasm, Energy by too much criticism in the beginning.
Once you have given them a problem, only monitor and provide hints as needed to help them solve the problem themselves i.e. you are only an animated "Rubber Duck". Let them get to some solution, its quality does not matter initially. Learning is a process of trial-and-error and adding of one knowledge chunk at a time to a mental model which you are building up during the process itself. Once they have a solution ready, congratulate them on their success which boosts their confidence.
Now comes the hard-part i.e. a postmortem of everything they have done where you point out mistakes (eg. edge cases which they have failed to consider, code design standards and correctness, proper documentation etc.) and show them how it is done professionally in the workplace. This will bring home the difference between "Hobby/School" vs "Industry" solutions. They then can rework their solution with these code characteristics in mind to come up with a "industrial strength solution".
1) Do NOT kill their Motivation, Enthusiasm, Energy by too much criticism in the beginning.
Once you have given them a problem, only monitor and provide hints as needed to help them solve the problem themselves i.e. you are only an animated "Rubber Duck". Let them get to some solution, its quality does not matter initially. Learning is a process of trial-and-error and adding of one knowledge chunk at a time to a mental model which you are building up during the process itself. Once they have a solution ready, congratulate them on their success which boosts their confidence.
Now comes the hard-part i.e. a postmortem of everything they have done where you point out mistakes (eg. edge cases which they have failed to consider, code design standards and correctness, proper documentation etc.) and show them how it is done professionally in the workplace. This will bring home the difference between "Hobby/School" vs "Industry" solutions. They then can rework their solution with these code characteristics in mind to come up with a "industrial strength solution".
- difficult to gauge how much they know, and how slow/fast I should in explaining stuff
Have you tried asking them? Just because you're supposed to have more experience than them, doesn't mean the flow of information should all be one way. Have regular chats with them about what they think their strengths and weaknesses are. Use these chats as a way to get feedback about your mentoring style, and make sure to take this feedback on board.
- distraction (I am excited to mentor, hence my brain keep coming back to that (providing resources, reviewing their work, etc.) while I am supposed to do my work)
This one's squarely on you and nothing to do with mentoring. Get better at setting the mentoring aside until it's time to do it. If an idea pops into your head while you're working on something else, note it down and go back to what you were doing. If there's prep work you need to do for a mentoring session, block out the time for it. You know, the things you'd do with any other aspect of your role.
- how detailed/nitpicking should I be in reviewing, how to explain the right concept at the right time
If you're talking about code reviews, you'll still be reviewing everything that you would for any other member of your team - you want to maintain the same code quality, after all. In terms of the concepts you spend time discussing in detail, probably just stick to one at a time - pick whichever seems most important for that review, have a short discussion about it, then decide whether it's something you need to revisit later or just watch out for in future reviews. If a short discussion isn't enough, book something more structured in and deliver more of a training session.
The important thing to remember is that everyone is different. We all have different experiences and learn at different rates. Be humble about mentoring. You'll find that when it comes to explaining what you think you know, you'll identify gaps in your own knowledge and probably learn as much as your mentee does. Use it as an opportunity for both of you to grow, and be receptive of feedback, even from a 'subordinate'.
Have you tried asking them? Just because you're supposed to have more experience than them, doesn't mean the flow of information should all be one way. Have regular chats with them about what they think their strengths and weaknesses are. Use these chats as a way to get feedback about your mentoring style, and make sure to take this feedback on board.
- distraction (I am excited to mentor, hence my brain keep coming back to that (providing resources, reviewing their work, etc.) while I am supposed to do my work)
This one's squarely on you and nothing to do with mentoring. Get better at setting the mentoring aside until it's time to do it. If an idea pops into your head while you're working on something else, note it down and go back to what you were doing. If there's prep work you need to do for a mentoring session, block out the time for it. You know, the things you'd do with any other aspect of your role.
- how detailed/nitpicking should I be in reviewing, how to explain the right concept at the right time
If you're talking about code reviews, you'll still be reviewing everything that you would for any other member of your team - you want to maintain the same code quality, after all. In terms of the concepts you spend time discussing in detail, probably just stick to one at a time - pick whichever seems most important for that review, have a short discussion about it, then decide whether it's something you need to revisit later or just watch out for in future reviews. If a short discussion isn't enough, book something more structured in and deliver more of a training session.
The important thing to remember is that everyone is different. We all have different experiences and learn at different rates. Be humble about mentoring. You'll find that when it comes to explaining what you think you know, you'll identify gaps in your own knowledge and probably learn as much as your mentee does. Use it as an opportunity for both of you to grow, and be receptive of feedback, even from a 'subordinate'.
Since I'm an intern I might give different point of view (Not a software engineer, but I think the principles might be similar). The person who mentored me in our first workday day he mainly gave me to talk. He gave me few tasks and just were next to me looking what I'm doing, writing notes (he didn't told me what I'm doing wrong on the spot, so I kept my flow).
The notes also had timestamp next to them, it was useful since he recorded the screen and I could watch it later on to better understand what I did wrong and how to improve it.
The notes also had timestamp next to them, it was useful since he recorded the screen and I could watch it later on to better understand what I did wrong and how to improve it.
- difficult to gauge how much they know, and how slow/fast I should in explaining stuff
Generally I think this is a difficult problem. Some people will agree and nod as if they understood everything without understanding anything, while others will ask dozens of questions when they already understand 99% of what you're trying to explain but just wanted to clarify details. I think the best way to gauge how this is with different people is to explain a problem or task, see how they react and how many questions they ask, then set them on the task and see how they solve it. That gives you a reference for if they agree to everything and solve the task quickly and easily they understood, or if they struggled it gives you an opportunity to talk about them asking questions and saying something if they weren't clear. You can use this to calibrate from there.
Additionally, I've found that people can be more forthcoming with talking about problems they're facing in a role in a more social setting. Going to lunch if in office or in some unstructured chat if remote.
- distraction (I am excited to mentor, hence my brain keep coming back to that (providing resources, reviewing their work, etc.) while I am supposed to do my work)
I think this is human nature to have your mind on the most interesting problem you're facing, which in this case to you at the current time is your mentee. It's something you just have to overcome to focus on your current task. If you have a team try to spread the reviewing across the team, this is helpful to the person as somebody else on the team may learn the same way they do and be able to explain something in a way that makes more sense to them and that's okay, as a mentor understanding that people need more feedback from different sources and providing a way for them to get that both frees yourself up and helps them.
- how detailed/nitpicking should I be in reviewing, how to explain the right concept at the right time
I generally think that nitpicking should be avoided in all reviews, point out things that are wrong for clear reasons and keep to your same review process you use for the rest of the team. Wrong could be opinionated if it doesn't fit the working style of the team. Explain concepts when they ask how something works, or if they have done something that is wrong.
Generally I think this is a difficult problem. Some people will agree and nod as if they understood everything without understanding anything, while others will ask dozens of questions when they already understand 99% of what you're trying to explain but just wanted to clarify details. I think the best way to gauge how this is with different people is to explain a problem or task, see how they react and how many questions they ask, then set them on the task and see how they solve it. That gives you a reference for if they agree to everything and solve the task quickly and easily they understood, or if they struggled it gives you an opportunity to talk about them asking questions and saying something if they weren't clear. You can use this to calibrate from there.
Additionally, I've found that people can be more forthcoming with talking about problems they're facing in a role in a more social setting. Going to lunch if in office or in some unstructured chat if remote.
- distraction (I am excited to mentor, hence my brain keep coming back to that (providing resources, reviewing their work, etc.) while I am supposed to do my work)
I think this is human nature to have your mind on the most interesting problem you're facing, which in this case to you at the current time is your mentee. It's something you just have to overcome to focus on your current task. If you have a team try to spread the reviewing across the team, this is helpful to the person as somebody else on the team may learn the same way they do and be able to explain something in a way that makes more sense to them and that's okay, as a mentor understanding that people need more feedback from different sources and providing a way for them to get that both frees yourself up and helps them.
- how detailed/nitpicking should I be in reviewing, how to explain the right concept at the right time
I generally think that nitpicking should be avoided in all reviews, point out things that are wrong for clear reasons and keep to your same review process you use for the rest of the team. Wrong could be opinionated if it doesn't fit the working style of the team. Explain concepts when they ask how something works, or if they have done something that is wrong.
Hello, this is coming from someone who was recently mentored.
- I assume it's a software engineering thing.
- I would recommend you to ask them to read: https://themissingreadme.com/ or provide them with a copy
- I assume it's a software engineering thing.
- I would recommend you to ask them to read: https://themissingreadme.com/ or provide them with a copy
- i only found about this book later, and it pretty much solved most of my problems and answered most of my questions in my first job experience.
- one major issue someone new to a work environment might have is how are people working, not the technical stuff, more of the daily workflows, prior assumptions etc
- example: https://strace.io/wiki/MicroProjects
In the introduction section, how to complete a microproject
- "Make the actual change. (Funnily, this is likely the only part is tought in college.) " <- this is so true and relatable
- shadowing, i think the best thing a mentor can do, is just share their screen during say two hours, and do their work
not just the technical stuff, answering emails, how and when do you respond to pings, how do you communicate progress or issues and when ...
these things might seem simple but they are not obvious to do.
- the book i mentioned talks in details about all the aspects of software engineering job and is easy to consult depending on the issues
the chapters are well named, e.i : Code review, Testing, .... so one can read a chapter as per their needs.
- one major thing mentors have to do is help pick easy to start with technical tasks for interns
initially most mentors pick extremely easy tasks
the issue comes in the second time, when the new person has familiarity with the workflow
(e.i has a properly setup dev environment, has access, and can make and commit changes, familiar with the code review process)
- mentors might pick tasks for em which seems easy, but easy is subjective, i personally found some hard tasks easy, and obvious tasks hard
always ask what the intern thinks about a given task and discuss it, most interns will be in the unknown unknown phase so they can't really tell if it's hard or easy for them.
the best way to help the intern absorb something is by showing how to do it, so critic is always vague IMHO if not accompanied with examples of better approaches, and that is very welcome.
Do you have any say who will you get for an intern? Do you know which areas of your expertise are the ones that intern wants to learn?
Give assignment and provide feedback latter. Have a lot of patience. Things that are self-explanatory to you might be out-of-this-world for intern.
Be a good listener. From questions you can conclude both interests and weak spots.
Give assignment and provide feedback latter. Have a lot of patience. Things that are self-explanatory to you might be out-of-this-world for intern.
Be a good listener. From questions you can conclude both interests and weak spots.
>difficult to gauge ...
Everything rests on this. Every person is different, and an approach based on a boilerplate will always be a bad fit. Think of what you are doing as a bespoke service and you will do well.
Everything rests on this. Every person is different, and an approach based on a boilerplate will always be a bad fit. Think of what you are doing as a bespoke service and you will do well.
A few things that I currently struggle with:
- difficult to gauge how much they know, and how slow/fast I should in explaining stuff
- distraction (I am excited to mentor, hence my brain keep coming back to that (providing resources, reviewing their work, etc.) while I am supposed to do my work)
- how detailed/nitpicking should I be in reviewing, how to explain the right concept at the right time
Thanks!