Mentoring: Getting the first software engineering job

We all know what mentoring is and have probably been or had a mentor before throughout our lives. For me, the last four months were my first time being a mentor. To give a bit of context, my brother Bill finished his Bsc in computer science, and he was looking to get his first job. I’ve crossed this road before, and I know that the early steps in software are quite taught, mainly because there is so much information and so many different career paths to choose from. So I proposed to mentor him on his journey, and he kindly accepted.

The Goal

The goal of this collaboration was to find his first job in the software industry. That was too broad, so we needed to define a bit more precisely what exactly we wanted for him. We had to determine what would be the expectations of this collaboration. After a few discussions with Bill and presenting him all the potential roles within a software company, we figured out that he wanted to work as a front-end engineer. He loved designing and building user interfaces and dealing with user experience. Now I am not a front-end expert by all means; however, getting an entry-level position wouldn’t be that difficult since the software fundamentals are the same, and I’ve worked with the javascript ecosystem in the past. So the goal was set: “Land his first front-end engineer position in the software industry”

First Steps

The first step was to evaluate Bill’s knowledge of the software. We did an exercise where we ran through some roadmaps to determine what is known and what’s not. I used roadmap.sh (front-end, back-end, and react specifically) for this assessment exercise where I could learn more about what Bill knows so that we can create our roadmap for achieving our goal. To be honest, it wasn’t something special; the exercise consisted of me questioning Bill about certain subjects while running through the roadmap like What is HTTP? and What are the HTTP methods? What is Git? etc. After a long meeting, I understood Bill’s knowledge depth better.

The output of this exercise was our initial tasks in our backlog. Our backlog consisted of several things that needed to be done to get to our goal. We agreed to meet 3-4 times per week for 1-2 hours each. The meetings were spread typically every two days where we could review the task’s progress, resolve Bill’s questions and decide the following tasks. We also reviewed our overall progress once every week to ensure we were on the right path.

After a week or two of working on this backlog, we could roughly estimate when we would expect to start sending our first CVs. Of course, we didn’t expect to be perfectly ready for landing a job offer. Still, we would need to do some stuff before applying for jobs like knowing the fundamentals of web development, knowing a bit about algorithms, building our brand, etc.

The Approach

We used Notion for our collaboration tool. We created a workspace in Notion where we had all our resources: backlog, meetings schedule, questions, projects, interview notes, pairing notes, everything! Every task in the backlog was separated into four categories: Learn, Brand, Practice, Interviews.

Learn

A learning task was a software concept that Bill had to study and explain and use in the future. A learning task could be Study about CI/CD or Study about Agile. In every task, there would be a description to give more information or guidance on how to achieve it. For example, in the Study about Agile task, I would add more information in the description like What is Agile? What is the alternative? Why do we need it? What are the benefits? What is Scrum? That helped us both since it enabled me to drive what I wanted for Bill to learn, and it guided Bill on what to learn so that he wouldn’t divert from the topic.

I suggested that the extreme learning technique helped me in the past. When Bill had to study a topic, he had to create a small presentation for me as well. That pushed him to understand the topic and gave me a way of determining if Bill learned the topic to move this task to done.

Practice

A practice task was programming exercises like solving algorithmic problems (easy ones), building small web projects, or adding features to existing projects using Javascript and React. An example of a practice task would be Add edit functionality to the bulletin board project, Solve the XYZ algorithmic problem in Leetcode, Add CI/CD to the bulletin board project. Practice tasks would also include pair programming tasks where we would pair together to solve a programming problem.

Brand

Bill didn’t have an internet presence before, so we had to build his brand. A brand task was consisted of building his profile in Github, LinkedIn, his CV, and his portfolio. The CV was the most time-consuming one, but after we built that, the rest of them were pretty easy as we had a baseline of his story.

Interviews

These tasks were the last in the backlog regarding priority. They consisted of mock interviews, both technical & behavioural. I gave Bill several personal interview notes to study and explained how the interview process works. I also interviewed him and guided him on answering both technical and behavioural questions.

Another interview task was to check the market, which was checking jobs on LinkedIn to better understand what the market requires in terms of tools, programming languages, soft skills, etc. This task was done twice, actually. We’ve done it once when we started our mentoring sessions to give him an essence of what is needed, and we’ve done it again at the end of our mentoring sessions to check if we are confident to apply for a job. It was pretty nice to see that he knew tools and concepts after four months of hard work.

Pair programming

A practice I used pretty regularly with Bill was pair programming. Pair programming is an XP practice introduced by Kent Beck, and it’s a great practice to share knowledge, collaborate and shorten the feedback loop. There were a few benefits of using this practice within our sessions.

When Bill was driving, I could give him feedback on his approach to common mistakes that junior software engineers make. Of course, I had to be careful and not interrupt him on every mistake he made, but give him space and let him think. Sometimes I would even let him corner himself so he could see the side effects on certain programming decisions. When I was driving, I could show Bill how I resolved common problems and approached errors and difficulties in software development. I had to be careful here as well to not rush on the implementations or assume that Bill knew things that I knew. So I constantly stopped and asked his opinion on certain aspects or the next steps. It was a constant feedback loop between us to learn good habits and techniques in software development. I loved our pairing sessions!

Final steps

After four months of hard work, we managed to get to the point where we could apply for a job. I warned Bill that this would be a difficult step since it would involve a lot of rejection. He is now applying for jobs with confidence, getting interviews in many companies, and getting rejected by many others. Unfortunately, it’s been two weeks since we’ve been applying for a job, so we don’t have an offer yet, but I will update this blog once it happens.

What we learned

Here you will find all the topics we covered throughout our journey (not in this particular order). The following list is not a list of what people should learn to land their first job; of course, every case differs. For example, in our case, Bill already knew SQL and how to deal with databases, which is essential for landing a job (even an entry-level one). You could argue that knowing all this stuff might take a long time, but the critical thing to note here is that every topic can be huge on its own if you dive deep. Getting some knowledge of all these topics is fine since we are only applying for an entry/junior position.

• Agile/Scrum/XP
• CI/CD
• HTTP
• REST
• Javascript convections & best practices
• ES6
• General Concepts like scope, event bubbling, hoisting, validation, and more
• Sass
• Clean Code practices (inspired from the Clean Code)
• Refactoring techniques
• Linting
• SOLID
• Single Page Application
• Git
• yarn/npm
• Static analysis tools (codacy, snyk.io)
• Github flow
• Dealing with behavioural & technical interviews

Recommendations

Feedback is an essential element in mentoring. You always have to give feedback on every step. Feedback was involved in every task. I gave feedback after every pairing session, presentation, mock interview, and almost everything. Of course, I was also constantly asking Bill for feedback since, as I said, I am not an expert mentor. With this quick feedback loop, I could see that Bill was learning faster since he was not making the same mistakes and constantly progressing. This is not as easy as it sounds. Giving constructive feedback requires practice. There is a way to deliver criticism without breaking your mentee’s confidence. Sharing your experience is a great way to send a message without criticizing them directly.

Give your mentee the space to make decisions. I did not own the board. It was me and Bill collaborating and agreeing on what to do next. If Bill didn’t feel writing code for a week, he could decide to pick up tasks that required studying or building his brand. It’s easy for me to take the wheel and assign tasks to him constantly, but it is healthier to give space to your mentee.

Empathy is another essential thing that you need as a mentor. It’s important to understand your mentee’s feelings and perspective. We all have days that we are less focused or with less energy, and it’s critical to be aware of that. I was always asking Bill if he could keep up for another algorithmic problem or if we should call it a day.

Last but not least, being a role model to your mentee is another crucial thing. Your mentee can learn a lot simply by observing and learning from your words and actions. They can pick up on how you behave and interact with the specific task at hand. If you’re stuck on a project, your mentee can watch to see how you react to any obstacles that may come your way. To set your mentee on the right path, show them multiple ways of handling difficult situations and talk them through your process. Allow your mentee to make their own mistakes so that they can learn valuable lessons from observing and learning from your own experiences.

My overall experience

I really enjoyed mentoring, and I realized that I could definitely support more junior people on their career paths. Is this the best way to mentor someone to get his first job? Definitely not. Is there a better way of doing it? Yes, definitely! But based on my experience and knowledge, I did my best to provide a sustainable environment to achieve our goal. The idea for this blog post was to write about my experience being a mentor and share some techniques on how to get an entry-level position as a software engineer.

I never expected to feel that proud by mentoring someone. I would certainly recommend trying it if you haven’t done it before. Mentoring is not only one way. I learned a lot through our sessions, both hard skills such as javascript react and soft skills such as explaining complex concepts simply. Other than that, the most important thing for me was to see my brother progress in his career. I was really excited that I could help him on his journey.