Internships and Placements are invaluable for getting a foot in the door and advancing your knowledge and skillset in a safe, supportive, and nurturing environment. But the cherry on the cake is mentorship. In this post, I detail 8 things I learnt from my own experience for how to make a mentorship as rewarding as possible, for both parties.

It's becoming increasingly common to stumble upon organizations who see the value in on-the-job learning and offer the full works for students or those new to the industry. So when I was accepted into a placement that ticked all of the aforementioned boxes, I rejoiced. And while I wish it could have been longer than one year, I valued every minute of my peers time and every ounce of their expertise. I noted much of what I learned on a daily, weekly and monthly basis.

When reviewing my notes, I began to see patterns of self-advice relating to my mentorship. As it turned out, by chronicling and triaging what went well and where there was room for improvement in my work and my self-development, I also began to form some thoughts and tips about how to get the most value out of mentorship for both parties.

I am by no means an authority on the subject, however, I wanted to share my advice for anyone participating in a mentorship - on either side of the table. It's a brief summary, so, I encourage you to seek other sources for further information and tips. In fact, I recommend this post entitled "Be a good mentor, not a dickhead" by edA-qa mort-ora-y which explores how easy it is to misjudge a new team member by their first few weeks and how to optimize the partnership.

I have more reflective posts in the works detailing my placement experience and progress as a developer. The purpose of this post, however, is to serve as a reflection on my mentorship and as advice for possible future ones. Of course, ultimately, I hope that it provides food for thought for all readers.

Build solid foundations

We start with the core of a mentorship - the partnership. Without developing a healthy working relationship and getting to know one another, a mentorship may struggle to provide value to both mentor and mentee, and therefore the organization. To build a good rapport is to lay the foundations.

The type of rapport built, both professionally and on a more personal level, will have a large impact on many of the other points later in this post. What it gives you is effective communication. Without good communication, all other elements of the mentorship will suffer, as will the resulting work quality. From confidence and self-belief to interactions and acceptance of mistakes - it all relies on a good understanding of each other in order to effectively communicate.

So how do we lay these foundations? In my experience, it's as simple as the first interaction consisting of sitting down one-to-one and just... chatting. You don't need to outline an agenda as it should be driven by genuine interest. Ask about one another's past experience, thoughts on certain languages, tools, paradigms, and patterns. Get to know each other's hobbies and passions. It doesn't need to be an invasive Q&A session - simply a chinwag. As you get to know one another, you'll be regularly re-evaluating how best to communicate with the other person. Moreover, you'll be evaluating how you communicate and where you can make improvements next time.

Is this a one-time activity? Maybe. But, it can only help to keep the partnership strong with short, open chats every now and then. My mentor and I would take small periods of time now and then to ask questions, impart wisdom, and engage in healthy debate or tackle whiteboard problems together.

Get on the same page

Consider this: what would be the outcome of climbing into a Taxi and saying only "Take me to my destination!" to the driver? You're not going anywhere.

A mentorship is no different - without both parties defining their goals of the partnership and expectations for themselves and the other, the ship is sinking before it has left the harbour.

When you do this is up to you. You could steer the initial meet-and-greet conversation this way if you feel it would be more beneficial. However, at the risk of meeting fatigue, it's a good idea to do this separately. We don't wish to muddy the waters on either of these two stages as they're crucial. By separating them, both parties are able to give each segment their full attention and take enough time to plan their discussion points and answers, giving the overall incubation stage of the mentorship clarity and value.

Both parties come to the discussion feeling fresh. With clear ideas and suggestions for the goals and expectations, alongside an ever-growing positive rapport, communication becomes a breeze. Everyone involved knows the what, why, and can begin discussing the how.

It's not a terrible idea to informally document these points as to relay them back to the higher-ups in the organization. However, it should be little more than a courtesy. Other than suggesting areas to address or projects suitable to work on together, the organization should really allow the mentor autonomy over the partnership, in my view. This improves the chances for the partnership to produce results by planning and reacting to change at the ground level.

Mentee: Show you want it

Remember that your mentors time is limited and that ultimately, you're still responsible for your work progress and self-development. If you don't show this, they may not remain as generous with it for much longer.

This can be done in at least two ways. The first is to show a willingness to do research and deliver your new knowledge to them and ask their opinion before giving your own with explanations. For example, during the planning stages for a database backed RESTful API and web-based client application, my mentor and I discussed the technology options available to us from end-to-end. By discussing suitable technologies, tools, and languages available to us, we could increase our ability to deliver in a timely and quality manner. To gather some more detail, I volunteered to research our various options and how the problem space has been approached by different companies. Then, I would return with insight, suggestions, and a list of pros and cons.

The second is the ability to identify a problem and propose potential solutions or alternative methods, rather than directly stating you have a problem and only asking for help. When stumped, refrain from calling upon your mentor immediately. Take some time to digest the information or problem and piece the picture together as best possible. Understand the problem space and formulate the areas of importance and potential solutions. It's highly unlikely your issue is unheard of or hasn't been discussed and solved elsewhere.

Always RS(E)A first, but be realistic - don't waste hours going around in circles. If you need to improve your problem-solving ability, check out this past post in which I discussed improving these skills.

The lesson of this section is that by showing your mentor you're motivated and making an effort to improve yourself, they'll see your ability to reason and act appropriately alone, making it less likely that it will turn into a hand-holding scenario. It also becomes an opportunity for them to suggest how you can improve your research and triage methods in the future. But, know that it doesn't hurt to ask for a walkthrough on solving the problem. Be sure to use all resources available to you - including other people. Admitting when you need help is an incredibly important characteristic to have for so many reasons. After all, Teamwork makes the dream work. Just show you've given it a go.

In addition, you can find some valuable but quick-to-digest advice for how to be confident in yourself and contribute to the team when on an internship in Gabriel Schwaiger's post entitled "Software Internship: What I've Learned & How it Changed Everything".

Mentor: It's a balancing act

Whilst I don't wish to state the obvious, balancing a mentorship with your regular workload may well be no small feat. But speaking from experience, the time you give is going to be appreciated - however much can be spared.

Now, as the mentee, I can't speak a great deal toward the mentor side of things. However, I was able to observe a few aspects of my own mentor which may be noteworthy. The first being obvious - a mentor must prioritize how they divide their time whilst still giving their protégé enough time, patience, and expertise.

What is enough? This should be covered when discussing the mentorship goals and expectations of one another. As the partnership progresses, the initial agreement of how much time and support required will be refined as you begin to experience how your mentee learns, at what pace, and what level they're currently at. It may be useful to nominate a secondary point of contact for the mentee to act in your absence. This way, if you are unavailable, your mentee is not left without a paddle, as they still have a peer to ask questions of.

Secondly, you should allow your mentee a certain breadth of free reign. A mentorship is not about micromanagement, but it is about providing a supportive partnership. Don't require that the smaller ideas or decisions be approved by you. For larger ones, it makes sense to go over the details and alternatives together, but try not to become another line manager. Giving the mentee a degree of freedom to apply and refine their critical thinking is crucial. The same also applies to creative thinking such as problem solutions and design ideas. Without a sense of responsibility, the mentee can't be 100% invested in their work. It becomes a to-do list as opposed to a personal journey.

Again, it's a balancing act. There needs to be an adequate level of support such that the mentee does not feel alone and is able to fall back on your years of experience, however, they must be given breathing room in order to develop themselves. So, ensure they're pulling their weight and upholding the expectations outlined to them in the beginning, but don't hold their hand.

Learning vs. teaching

In addition to outlining expectations and goals, it's vital to outline the forms by which a mentee will learn effectively, and align that with how the mentor prefers to teach. It's a good idea to find methods which both parties find optimal.

For example, the mentor may prefer to teach by encouraging their student to research for themselves and prepare questions and talking points to solidify their understanding before returning at a later time to discuss it. However, the mentee may well prefer to learn by getting hands-on with the technology with their mentor alongside, such as pair programming.

Determine who bodes best with which methods and strike an optimal balance. In the above example, it's unrealistic to expect the mentor to be available to pair on demand when an issue is encountered or when something new must be learnt - it causes a domino effect of disturbance and occupies a lot of time. And the mentee shouldn't expect them to. It's as much about developing ourselves as it is software. So the mentee should strike a balance and make the effort to seek this information for themselves and experiment, then return to discuss and clarify their understanding.

Regular interaction

Interaction should be regular and face-to-face as often as possible. Email, Slack, and internal IRC are powerful for quick updates, questions, and bot output. But anything more should be explored in person.

However, more importantly, I found that these face-to-face interactions should be scheduled. By arranging agreed-upon periods of the day for open Q&As, whiteboard brainstorming, idea or progress feedback, and pair programming sessions, both parties are able to better value one another's time and reduce distractions and interruptions. Thus, giving their workdays and the mentorship stronger structure. Scheduling interactions is important whether you're in another building or next door to one another.

Walk-ins can and will still happen, however - for both parties. Both should be honest about their availability at that moment. If time is tight or in the midst of a problem, suggest a time for them to return. Let's not forget that just as crucial as scheduling time to meet, is the explicit definition of periods where either party wishes not to be disturbed unless the building is on fire.

Feedback is Key

We all like to hear that what we're doing is right and producing value. Often, there are at least two types of feedback: that which is requested, and that which is awarded. For example, demoing an MVP application to your stakeholders and project participants in order to gather more insight and adaptions to make is a form of requesting feedback. On the other hand, hearing praise from a peer is an example of being awarded feedback.

For mentors, it's important to praise good ideas, contributions, and initiative. This is awarded feedback. This will reassure the mentee that they're good at doing what they love (there is little as emotionally draining as not having that reassurance). In situations where those things may not be up to scratch, mentors should accept the state of the artefacts and give constructive feedback and demonstrate ways to improve next time. Don't allow yourself to appear the disproving professor who states "You should know this...". Instead, find a way to support them by teaching it in a way where they come to know it as their own name.

However, it is as important to provide requested feedback, also. If your mentee emails for a quick word on a proposed document structure, a function, or their understanding of something, be sure to reply. Code review is another great example of this. Whilst it is now ever more common for it to be organizational policy to perform code review, a mentee who might prompt for it or send a reminder that a review is open, and actively discuss the feedback is a mentee who wants to grow. Furthermore, it's a great example as it allows for a mentee to gain peer feedback from those other than their mentor, which in turn, acts as feedback for a mentor as to where their colleagues think may be areas to improve or cover in addition.

Mistakes happen

I think this one needs to be last as to have the most chance of being remembered. Mentee - no one expects you to know everything out of the gate. Your peers know and accept that you will make mistakes. They accepted the responsibility to train you to the best of their ability, which includes teaching you where the pitfalls are and how to navigate around them.

But, mistakes will happen. So what kind of mindset should we have? Should we fear or avoid making progress on tasks in the case of failure? Should we avoid taking risks or learning new things altogether? In my opinion, we should celebrate the small-to-medium mistakes. If we screw up, we triage why and we plan to mitigate against it in the future.

Upon realizing a mistake, your superpower is having the ethical values to be transparent about what has happened to your peers in a solution-oriented manner. For less consequential mistakes, if you know what went wrong and why, and you have a fair idea how to resolve it - do it. Don't forget to mention it next time you speak with your mentor. This way, your mentor will be better equipped to further gauge the level of support required with regard to your work, self-development, and study.

If the consequences of it were more serious, there most important steps to take are:

• Evaluate the problem and its consequences. Be sure you understand what has happened, and why. No one is going to appreciate a fuzzy description of the problem and its consequences if it is serious.
• Remain calm and think rationally. Pressure, fear, and stress are destructive emotions. Allowing them to overrule your thoughts, skills, and actions will not help anyone.
• Don't hesitate in relaying this information to your mentor, or if they're unavailable, another suitable peer.
• Take responsibility. Mistakes happen - don't try to hide it or deflect it if was an honest mistake. Be responsible for your mistakes in the same way you are your successes.

Understand the problem and try to hypothesis the 'why' element to have some reasonable ideas about how the mistake came to be, and how to resolve it. Make sure you are solving the problem, however, and not just treating the symptoms.

When you approach your Mentor, explain your mistake simply, then with concrete details about the problem and current state of affairs, and then give potential and actual solutions or ideas. This way, the focus is toward triaging and remedying the problem - not playing the blame game. The simple act of being transparent and honest says a great deal about your character and ethical values as a developer.

Conclusion

I hope this has proven useful. While there may be some recurring themes through each point, I hope those might make clear how many of these sections relate to one another in practice.

I may update this in time, should I ever participate in another mentorship on either side of the table. For now, I hope it has served as an interesting primer for getting the most value out of a mentorship for all those involved.