Introduction
I am in a unique position right now: I am a Junior Software Engineer filling in for a Tech Lead for two weeks, covering two internal projects filled with other juniors, trainees, and interns. This means that I am both a junior and acting as a guide for juniors at the same time.
This isn't the first time I've played this 'double role': when I was completing my year-long training in web development, I was both a student and a class tutor: learning and teaching at the same time. There is a lot to be said for this: namely, that teaching helps you learn as well.
Additionally, this unique position allows me to provide insight on how best to support junior developers with the advantage of both perspectives: that of the junior, and that of the supporter.
All that said, let's talk about ten things you can start doing to better support your juniors today. Spoiler alert: a lot of it comes down to communication!
Table of Contents:
- Define expectations and timelines
- Emphasise trust
- Provide choices
- Avoid minimisers
- Avoid solving problems for them
- Ask questions
- Review tickets with why
- Give regular feedback
- Go beyond technical conversations
- Ask for regular feedback
- Conclusion
1. Define expectations and timelines
It can be extremely disorienting to enter not only a new workplace but also a new industry. If you are in charge of guiding the path of a junior, it is your job to explain to them as early as possible what that path will be, what is expected of them, and what kind of timeline they'll be working with.
"For the first month or so, you and I will be working closely to have you trained up in Java for the backend, including testing and basic microservices. There is no set timeline for this, but once you feel you're ready to move on, we'll then look into Docker and other containerisation technologies. The goal is that by about six months into your time with us, you'll be comfortable and confident coding the backend for bigger projects."
Alternatively, you could speak more broadly:
"As a junior, we really want you to focus on learning and asking as many questions as possible. You'll have a chance to explore a lot of different technologies, and after around a year we can talk more about which you'd like to specialise in."
It is also important to speak directly about what you expect (or don't expect) from them:
"Our expectations in your first few months is that you get to the point of being able to solve a few tickets, but we don't expect you to be an expert or to complete them without any assistance."
By having these conversations, the journey of their first year won't seem quite so daunting: this kind of structure can provide a better sense of security. This allows them to have some soft goals to work towards, but also gives them an understanding that they are not expected to be an expert.
2. Emphasise trust
A lot of juniors will be entering the industry straight out of some sort of study situation, be it a bootcamp or a degree or self-study at home. As a generalisation: the younger or newer to the workplace a junior tends to be, the more they will tend to try to impress you and not tread on any toes. This is not a good thing: you want honesty and you want to know exactly where they stand with the technology.
Often juniors are so caught up in trying to impress you, since they're often suffering from Impostor Syndrome and trying to prove themselves, that it will be hard for you to get an honest assessment of their skills and abilities, and any attempt you make to do that directly could embarrass them.
Instead, try to build a relationship of trust.
For example, when I first began I told my Unit Lead that I had a dentist appointment on that Friday and I wanted to know if that was "OK". His response was perfect:
"I'm not here to micromanage you. I trust you to handle your own schedule and complete your hours as you see fit."
Additionally, you need to be transparent about not knowing things, and to talk about it openly with your juniors. One trainee asked me about the difference between casting and parsing, and my response was:
"Great question! I think I know, but let me check so I don't feed you false information."
This models the kind of behaviour you want to see: honest conversations about what we do and don't know, and an openness to being wrong and checking for the latest info.
3. Provide choices
Very often, a company or team will have a structured onboarding process. This is usually a great idea, but there has to be wiggle room for individual responses. Where possible, try to find small ways where you can provide options. Give optional 'bonus assignments', provide multiple tracks of specialisation, or offer for the junior to come into meetings they wouldn't normally be in so they can see how things run.
Early on in my time at Novatec, I was invited into a few meetings with the Software Reliability Engineering team in our Spanish office. I barely said two sentences, but getting to see how different teams worked together was highly valuable for me, and I felt special being invited.
Now, as an Acting Tech Lead, I've offered opportunities for trainees and students to work with me on topics, or to sit in on workshops that are too advanced for them (for a half-hour or so), so they can get a taste of what is to come. Nobody has to do these things: they are offered up as choices for additional involvement/observation/learning, and the junior is free to take it or leave it.
From your perspective, this is also a good way to see what opportunities interest individual juniors, and what opportunities don't. This can only help you further personalise your interactions, and perhaps also flag early which areas could be their future specialisation.
4. Avoid "Easy", "Simple", "Basic", and "Obviously"
This is one of the most important but most difficult habits to break.
In my position, we work with a lot of trainees with little or no programming experience.
- How do you think this person will feel if I talk about how "easy" HTML and CSS are and then they get stuck learning Flexbox?
- What about when they ask me how to turn a string into an integer and I say "Well obviously you need to parse it" and they don't know what parsing means?
- What if I tell them to try some "simple exercises" and they get stuck only 5mins into trying?
As someone with a bit more experience, it's easy to forget how hard things are at the beginning, and how much of a change in thinking programming often requires. Things that are easy, simple, and obvious to you are not necessarily that way for a junior.
Your goal might be to make concepts seem less intimidating, but what the junior hears is "you're supposed to know this and you're ignorant if you don't". Remember Impostor Syndrome? A lot of juniors are also career changers, and when they have it implied that something is obvious that they don't know, it can trigger a broader fear of not belonging.
That, in turn, means they're less likely to ask the follow up questions they should ask:
- "Flexbox seems to be holding up my progress, do you have any good resources on it?"
- "Sorry, what does parsing mean?"
- "I'm stuck on the first exercise, can you help?"
5. Avoid solving problems for them
Let's say, though, that they do ask the right questions. They do ask for help. What comes next? Presumably, like any good mentor, you're ready and willing to help them solve it. Wonderful!
If you're in a position to guide a junior, then you most likely are a problem solver, and your instinct will be to solve their problem as quickly and easily as possible.
Unfortunately, that instinct is not the right approach. You need to give them enough resources to solve the problem, without actually solving it for them.
For many beginner issues, the problem will be not knowing the correct terminology to Google: in this case, the answer could be as simple as saying "Try looking up information on CORS".
But let's say they have the information, and still don't know how to proceed. The next question should be "What have you already tried?". This achieves two things: it ensures they've actually tried to solve it themselves (which helps promote initiative); but it also gives you an idea of how they're thinking about the problem and its solution.
In short, try to ask leading questions or make suggestions for future research, rather than just saying "Oh that's easy just use a loop".
6. Ask questions
It's not just the junior who should be asking questions, it's you as well. Asking questions allows the junior to repeat and articulate concepts that may otherwise be unclear or not totally solidified in their minds.
Try some of these:
- "What kind of problems do you anticipate for this ticket?"
- "What kind of tests will we need to write?"
- "What should happen if a user enters text instead of a number?"
- "Do you think we should use an integer or a double here?"
This step is particularly important for juniors and trainees who aren't asking a lot of questions themselves. These kinds of points allow you to gauge where a junior is at in terms of their knowledge, which means you can better tailor your responses to their level. If they can answer the fourth question clearly, but can't answer the second question, then you know they have decent programmatic knowledge but less testing knowledge. This is good information and means you can help them with finding appropriate resources.
7. Review tickets with "Why?"
Your junior has completed a ticket and/or has asked you to review their code, terrific! One great piece of advice I received recently from my own Technical Lead, is to always ask "Why" in these scenarios.
This is especially the case if, like me, you're still new to the project yourself. Even if not, trying to understand the perspective of your junior is always worth the extra time it takes to ask more probing questions.
If someone has solved something in a way that would never occur to you, this is especially important to ask, as it avoids you perhaps jumping to the conclusion that it is just wrong. Sometimes the fresh eyes of juniors can bring things to our attention that are new or different, and taking the time to understand that perspective could actually help you improve your codebase.
In addition to that, asking 'Why' might also highlight misconceptions the junior has about the codebase itself, which in turn could help you with refactoring or making the flow of information cleaner. After all, we want human-readable code that is as simple to follow as possible.
8. Give regular feedback
One of the hardest things to do as a senior is to give honest, regular feedback. Let me teach you a simple strategy for doing so, called the "compliment sandwich".
- Lead with a compliment
- Insert some constructive criticism
- End with a compliment
Here's an example of a compliment sandwich:
"I wanted to share with you some general feedback about your progress, since you've now completed your first week. Overall I'm really happy with how many questions you've been asking: it's clear you're really engaging with what you have to learn and are being honest about your progress. I got a comment or two from coworkers that sometimes you interrupt them in group discussions, so ideally that's something you could work on for next time. Other comments I received said that your sense of humour is really refreshing during routine meetings, though, which I know is greatly appreciated by all of us!"
This gets the point across: "people are noticing when you interrupt, and it's a behaviour which isn't good for the team". However, it's also not making it into a bigger deal than it needs to be, and the junior won't come out of the engagement thinking that everyone hates them, which is naturally a concern of someone new to any type of group.
The other benefit to this type of feedback is that it leaves room for a different approach when something more serious does happen. If someone is yelling at teammates, for example, or making discriminatory "jokes", you can pull them aside and be far more direct, and they will know that it is serious because THERE IS NO SANDWICH.
9. Go beyond technical conversations
Sometimes you see a junior lose the wind in their sails. They look deflated and defeated, and are not being their usual selves. This is the time to enter "Mentor Mode" and shoot them a quick message or have a quick chat with them: "Hey, you don't seem quite yourself today. What's going on?". If they make it clear it's not to do with work, then you need to also make it clear that that's OK: "No worries, you can still tell me about it."
I have been on both sides of this conversation. Both times, I have come out feeling closer to the other person and it has built trust between us. It feels good to know that someone is noticing when I'm down, and that I'm not bound by what is considered typically professional when something is impacting my work. Similarly, knowing what is happening in the personal lives of others, especially when it is serious and impactful, means that we won't rush to make judgements about their work performance or personalities.
You might also find that someone is dealing with typical issues such as impostor syndrome. In these scenarios, it's a good idea to share your own experiences, how you felt when you started your first tech job, etc. Knowing that you understand, or at the very least acknowledge, the impact of these feelings can lead to even further trust and helps establish a solid working relationship.
Of course, if the issues are beyond the scope of your abilities to handle or support, there is also nothing wrong with saying so: "I am here if you need someone to talk to, but I'm not a professional and this sounds like something you need to discuss with someone who knows more about it". Definitely don't give unsolicited medical advice for medical issues (e.g. depression, anxiety, phobias, etc.).
10. Ask for regular feedback
Last but not least, remember that the flow of information should never just be one-way. None of us are perfect, and we all mess up. Similarly, we all have skills we can work on. If you're new to guiding juniors, take the time when giving them feedback to ask them "Is there any way I can support you better?" or "Have you got any feedback for me from our time together?".
Try not to phrase a request for feedback as a statement, such as: "I hope you've found our time together useful". This begs for a compliment and does not provide an open environment for honest critique.
Better still, if there are a few members of the team who you know tend to brutally honest or lack a filter, then it's worth shooting them a message and saying "If you have or hear any feedback on me, good or bad, I'd love to know". This again builds trust, but you also know that if word starts going around 'on the grapevine', you'll hear about it.
Although of course, you have to be ready to hear negative feedback, just like when you were a junior yourself. Honest critique, even when constructive, can still hurt; but it is essential not only to your own progress, but to that of the future juniors you take under your wing.
Conclusion
Build trust, have an open ear, and be ready to read between the lines. Nurture your leadership of juniors and their progress will not only reward your company, but your soul. You can probably recall someone who lifted you up and gave you faith in yourself in your early days. Be that for someone else and you can change their lives, even if only for 20-40 hours per week.
You got this.
