How to grow your junior engineers

Katie Jones
Aug 16 · 9 min read

I have been working within the iOS team at Gousto for 9 months now; I started with zero professional experience and came through the door as a career changer. There are now more than a dozen career changers here and with the launch of our new Talent Academy, this number will likely double within the next year.

To get straight to the point, after a few months in my new role I had assumed my experiences as a first time developer were unique to me. As my communication and conversations with other early stage software engineers became more regular and in-depth I realised this wasn’t the case. We had all shared similar experiences in our first year as an engineer. Areas emerged that seemed common and potentially universal and I couldn’t ignore the value others may find from me documenting them.

To shine a light on what resonated with us and to promote our ethos of honest feedback, I have collated the most common themes and have presented them in a start, avoid, continue structure. As mentioned above, the number of juniors joining us are going to grow this coming year making this feedback all the more important. This post will help celebrate what has set us up for success so we can continue doing these while outlining what is potentially slowing down a junior’s progression. The purpose of this post is to learn from experiences and is aimed at leaders, experienced developers and more specifically, anyone interested in mentoring.

Start 🚦

Setting expectations early on

It is important to communicate what is or is not expected from juniors early on. Something along the lines of: “Our expectations in your first few months is that you will work on tickets, but we don’t expect you to complete them without any assistance.” This is particularly important when a junior is asked to work on tickets alone. If a junior hasn’t yet inhabited a trusted environment, they may feel uncomfortable reaching out for help. In a personal experience shared, being given tickets to work on solely gave a perception that they should be an expert in an area and they were therefore reluctant to reach out for help when they were blocked.

If you search for software engineering memes, you will find many joking that our job is Googling, and the funny thing is that this is in the most part true. However, this can be daunting for a junior as we find ourselves having to research the answer for everything we work on. More apparent to career changers is that software engineering is one of the only industries where Google is accepted and recognised as a credible source. Let them know this is a key element to problem solving and that as a senior, you probably find yourself Googling the same things we do. This creates open environments and shows that they aren’t expected to complete all the tickets they pick up on their own from muscle memory.

Educating that agile processes help us track team velocity

If this is the junior’s first professional role as a developer or they’ve switched careers, this may be their first time practicing agile processes. Start by educating juniors that agile processes and ceremonies in the fundamentals are there to help us work in a structured manner, empowers us to collaborate effectively and helps set expectations. Ensure that they understand things like why we size tickets and why it is important to regularly inspect and adapt our workflow stages to ensure work is flowing through the system. If you are sizing a ticket, spend some extra time helping them to understand the smaller details. This might be that you explain that your team allocates points based on the most senior developer carrying out a ticket. It can be daunting for a junior to agree to a point that feels way more optimistic than they can achieve, then pick it up and have to report in stand-ups that it’s taking longer. Let them know that it’s ok if a ticket takes longer than you pointed it at sometimes. Hey, it happens quite often down to a number of different reasons.

There are more ways we can help a career starter onboard more easily to agile principles like adding them to the #guild-agile Slack channel. Here, they will find many useful resources and training material. Do also add them to the guild meeting invite so they can attend and listen to the topics we discuss. This will introduce them slowly, and they can choose whether to join in on the conversations or simply sit back and absorb until they get more familiar and feel comfortable participating. This way, we give them the choice while exposing them to key, real world topics that are raised in the workplace everyday.

Helping juniors find skills to work on in their first months

Many of us felt we had a lot of time to dedicate to learning in the first few months but were unsure what learning to focus on. We felt very much like a generalist, trying to learn a little bit about a lot and not focusing on any one thing for very long. Receiving structure around what skills a junior should focus on over the first few months would help us use our learning time more effectively when we’re in this stage of uncertainty. We think it would be super beneficial for future juniors to join more experienced developers on one of their learning projects. For example, on Tech Ten Percent — a day dedicated to learning and innovation every 10 business days. This will expose them to the sorts of things they might eventually work on themselves, as well as witnessing more experienced engineers approach solving problems. It will also expose areas they haven’t yet came across.

Avoid 🛑

Using assumptive language

Are you using phrases like “easy”, “straightforward”, and “just need to do this” when describing a ticket? Juniors are already feeling imposter syndrome and if they have no experience or previous exposure to the concept you are discussing, then it is neither easy, straightforward, nor clear the approach they should take (sometimes). Replace those words with phrases like, “have you ever worked on this before?”, or “would this be something you’d feel more comfortable pairing on?” During refinement and discovery stages, instead of sharing screens, skim reading files and moving from one class to another explaining how you just need to do this, make a habit of writing class names and implementation details in tickets. When following someone else’s screen and trying to absorb information, we are likely to forget referenced classes and small details in between refinement and implementation. Many have shared that this has worked really well in their teams for everyone and not just for the benefit of juniors. It also helps save time and prevents repeated explanations.

Asking career changers how they can add value

For many of us career changers, there can be a lot of early focus on how we can provide value to our team using our existing skillset. This is useful to feel like a valuable member of our team, but many of us find that it is distracting us from what we think should be the main focus at the start of our career → building our technical skillset. Some of us regularly find ourselves doing a lot of glue work to be recognised for our already established softer skills in order to make up for the lack of technical skills we have on paper. Because of this, we are more likely to take on roles like agile champion early on and less likely to admit that we don’t have the capacity for it. Though this gives us exposure to agile methodologies and helps us integrate into the team, we also balance learning to code, getting up to speed with how the company is structured, learning how the codebase is architected as well as implementing tickets and many more. All of this in the first couple of months can be overwhelming and takes away many hours from coding. One way we think would relieve pressure is asking juniors whether they have the bandwidth to take on another task before being automatically added to role rotas. Read more on this here to understand how glue work can be damaging for anyone who isn’t in a senior position.

Continue 🙌

Pairing on code review feedback

Generally, we feel that code review feedback and comments are clear and constructive. Some juniors have found it extra helpful and appreciate when they have been asked if they would like to go through the comments on a call and pair on what is being suggested. We’ve found that sometimes we can misinterpret a comment and as a result of this, there tends to be quite a lot of back and forth and after a few commits later, we finally get approved. Jumping on a call and pairing on feedback really helps us to get more context, it saves time, and we learn how not every code review comment is equally pressing. Not to forget it also means our code is written to a higher quality and pull requests are quicker and easier to review the second time round. This is something we would like to celebrate and share for visibility as we want to encourage all teams to do this.

Checking in

Juniors are encouraged to ask questions — it is one of the few expectations companies have of juniors in their first year. However, we find ourselves asking questions all day long which can quickly make you feel out of place. We recommend giving more than what is asked for as what might be easy for a senior, is not necessarily easy for a junior so we really need to make sure we go the extra mile in the first few months. We have appreciated it when our more experienced peers check in to see how we’re getting along on a ticket or proactively offer to help once in a while.

Tip: Pay attention to how a junior is reporting their progress in standups and respond accordingly. It can be as simple as “how’s your ticket going, do you need an extra pair of eyes when debugging?” after the call has finished.

This is extremely important to ensure we regularly continue to do this while working remotely. When we’re in the office we can recognise when someone is finding something difficult through social cues and are more likely to go up to someone and ask them how they’re getting on. Being remote, we lose the ability to pick up on those cues and therefore it’s important to make sure we’re not losing our support network as a result.

Giving Feedback

No matter what we learn from our university degree, coding bootcamp, or online courses, there is much more to learn when working on a real application. These might involve: CI/CD, source control, reading and refactoring other people’s code, scaled design patterns just to name a few. It’s very easy to get lost in material, concepts, and generally keep track of our progress. Not only keep track, but also understand if we’re on track. For many of us, being the only junior in our team means we’re speaking less to other juniors on a daily basis. When we’re working with other juniors, we find that we’re generally asking the same questions and receive a +1 on concepts we’re finding hard. What that reinforces is that we’re learning something that is generally difficult for our level and not necessarily us as individuals. However, this should not be the only measure for our progress and we’re happy to share that it isn’t! Many of us regularly receive feedback. A good example of feedback is when we’ve been acknowledged for doing something well and equally, when our seniors identify areas to us that they think we could spend more time on. Please keep this in mind when reviewing our pull requests, it helps with our motivation and is key to us improving. 👐

And that’s our top tips for supporting juniors in their first year. With special thanks to Andrew Perkins, Nora van den Heuvel, Kira Slobodina, and Rianne McCartney for opening up about their experiences with me, and sharing their honest advice. N.B. This post was written from a junior perspective. Where the word ‘we’ has been used, we is the voice of the juniors involved in the making of this post and not the voice of Gousto.

And remember, everyone was once a junior. I’m sure for many they have that one person they notably remember being supportive in their early days. Be there for someone else ❤

Gousto Engineering & Data

Gousto Engineering & Data Blog