I was one of the first Junior Engineers joining GDS, and at the time, there was no official mentorship program. Working in a team was helpful but it was not enough; I was still a student and I really needed to overcome my impostor syndrome. But as they say, “if the mountain won’t come to Muhammad then Muhammad must go to the mountain” – therefore,I decided to design my own mentorship program.

This required me to find a mentor that was able to provide support and help me work on my weaknesses. Being an “ask” person (story for another post), it was easy for me to ask a trusted colleague who had previously worked in my team to become my mentor. David happily accepted.

Meeting format

Initially, we sat down to identify what would be useful to cover in the mentorship.e agreed that it should help me both with quickly becoming a productive member of my team and, more importantly, with building a solid basis that enable me to develop as an engineer and move out of the ‘junior’ role.

Together, we identified the topics every engineer who works in web development should be familiar with (*). We also did some mock interviews, which helped develop my presentation and communication skills. One of these interviews included a systems design question that revealed some gaps in my knowledge which we could then fill in the following meetings.

At the end of every meeting, David would send me a summary of what we covered so that we would be able to keep track of our progress.

Tweaking

Often, after our meetings, we reflected on what worked well and what did not. We tweaked the format until we found something that worked for us both. For example, we:

• Planned the topic to cover in the following meeting

Sometimes, David gave me a little homework to do for the next session. This could include reading some blog posts, documentation, reports or research.

• Decided the agenda at the beginning of the meeting
• Met with no agenda and we set on the fly
• Initially met once a week, then fortnightly and finally once a month

Keep iterating on your sessions as you go along, as your needs change throughout the mentorship.

Terminating

It is common that a mentorship will come to an end or you start meeting less and less often as I did with David during the years. Remember that the mentorship should keep going on as long as it makes sense for both of you. Be responsible and open with one another.

Reflections

As we kept hiring new junior engineers, we shared our findings with them and their managers. Seeing as it was well received, line managers started  to find out whether their reports would be interested in and benefit from being mentored. I would advise to meet with the potential mentors for your reports. This will allow you to choose the person that would best fit their needs. Also, keep in mind that being a line manager is completely different from being a technical coach/mentor. Be wary of mixing the two.

Overall it was a great experience that helped me and my mentor grow professionally. Thank you David!

______

* Here’s a list of some topics we have covered:

– OO

– Types of databases

– HTTP

– REST

– OWASP’s top 10: The 10 most common vulnerabilities in Web Applications and how to protect against them.

– Architecture design

– Database design

– Microservices

– Refactoring

– Deployments

– MVC

– SQL syntax

– OAuth

– Design Patterns: David tried to give me an historical perspective so I could understand that even ‘big ideas’ like design patterns can be inapplicable when the context has changed. Not that design patterns are a bad idea, but rather that the gang of four design patterns were developed in a different context which is quite different from modern web applications.