Get Yourself a Junior, or How Software Development Teams Can Benefit from Recruiting Junior Engineers

Every now and then, you might hear about software companies withdrawing their junior positions, or even freezing recruitment completely. Frankly, it shouldn’t come as a surprise to anyone acquainted with the current economic and technological trends. After all, who has the certainty required to heavily invest in training a rookie, amidst fears that the entire IT sector may face cataclysmic changes at any point in the near future? And aren’t we all getting replaced by AI soon?

People with much longer tenures have been trying to answer these questions and still haven’t come to a conclusion, so I’m not even going to bother. Instead, I’m going to make an assumption, or an educated guess, that the tech world is not going to implode overnight and that flesh-and-bone programmers will still have to fix AI-introduced bugs a couple of years from now, or vice versa (it’s a symbiotic relationship). There are good reasons why companies need to look into hiring junior developers rather than rely solely on senior experts. By bringing on less experienced employees and training them effectively, organizations can reduce talent shortages, tap into fresh ideas for innovation and improve employee retention.

To help you gain these benefits, this article will focus on how to introduce and engage your freshly acquired junior engineers in a way that gives your team a tangible boost as fast as possible.

From the perspective of a junior software engineer

I’ve read that people react more positively to stories that have a personal touch, so bear with me – I’m a newcomer in the industry. I’m probably a bit older than most people that start their first IT job, so hopefully (though unlikely) I’ve acquired some common wisdom from my previous experiences, but when it comes to coding, I’m a greenhorn. I’ve made the decision to change careers just around the time everyone started saying that programming is doomed, so feel free to judge that “common wisdom” on your own.

In May 2023, just before I graduated from my bootcamp, I managed to land my first software development job. Since then, I’ve been told I made blazingly fast progress, so that’s nice. What’s also nice, and unexpected, is that I feel it’s kind of true – even though I’m not yet in a spot that would satisfy me personally, I can definitely see that my contributions have an impact, that my voice is heard and listened to and that my team is better with than without me.

But what’s the most surprising is that I got that feeling almost immediately, not even a month after I joined the company, and after witnessing the same thing happen to two other junior engineers, I believe it’s not a matter of a stroke of luck, a peculiar alignment of stars or even our own particular excellence of character, but the result of a well-crafted onboarding process. Even though I’m not going anywhere any time soon, I can already see me feeling nostalgic about the way I was treated in my “first” job, so I decided that the best course of action is to describe my experience to team leaders and delivery managers so that more engineering teams can get better return of investment on their junior software developers – and so that new hires can start contributing to their projects sooner.

Step 1: Get your juniors a tutor

This observation is getting more widespread nowadays, but it’s worth reiterating: approaches like pair programming or the Buddy System work. It might seem counterintuitive to assign an experienced person to babysit someone who at best makes a fourth of their salary, but it’s not just about bringing the newbie up to speed – it’s actually about gaining a better understanding of your team’s workflow and culture.

Don’t hand your junior team member a description of required code style and your Git workflow. Instead, pair them up with your highest level wizard for a day or two (it really is enough) so they can watch the development of a minor feature from conception to completion. Show, don’t tell. Not only will your junior immediately grasp your actual practices, but they’ll also get acquainted with your top wizard, which means they’ll be less intimidated to seek help from them later on.

Step 1b: Help them with distractions

Anyone working for a large company has to deal with some level of nonsense or bureaucracy: tasks that aren’t related to their actual work. Some of it is justified, some is necessitated by regulations or external circumstances, and some could be removed without anyone feeling a difference. Great companies keep the distractions low, but some hindrances are always there.

Shielding a new employee from as much nonsense as possible pays off in the end. I’m not even talking about the cost-time ratio (your seasoned developers are certainly more costly, even though they probably already wrote some shell scripts to automate the nonsense), but again – it’s about understanding what it means to work in your team.

If my first month of work involved one hour of coding and seven hours of convincing your managers that you can’t work any faster, I’d probably subconsciously assume that this is how everyone is supposed to work on the team. After all, there are many career paths in which that’s exactly what you have to do (certain government positions, even some construction work). Even in IT, at some level of seniority, you start to write less and less code, so that one hour per day may become realistic at some point. But at least for now, I was shown early on that my integrated development environment, not MS Teams, is my primary work tool. It helped me establish an inner rhythm and expectation that my job is to code, which worked wonders for my motivation and productivity.

Step 2: Throw them off a cliff

The trick lies in realizing that for a junior, everything is a cliff. Handholding goes a long way at the very beginning, but at some point, it just prevents the new team member from making a splash. As soon as you feel at least 75% confident that they aren’t going to accidentally delete your databases, give them a challenging task – something that you are pretty sure they’ll struggle with.

First of all, good engineers usually have the type of personality that responds well to challenges, and second, I know I learned more from the first time I failed than from a dozen tasks I completed effortlessly. Perhaps most importantly, I learned that failing is not something you need to obscure and that the best course of action is to report problems as soon as possible and look for solutions together (as a team leader, make sure that this is indeed the best course of action in your team – it’s not just about approaching the juniors, but rather about building a good work environment).

My first real task had to do with logging exceptions. In Spring Boot, that mostly meant writing some really basic @ControllerAdvice and @ExceptionHandler annotated methods, yet somehow I managed to botch it. Fret not – my fellow wizards stepped in and helped me refactor my solution into something presentable, so in reality they were the ones who did the hard work, and I was just the assistant who typed private final everywhere. However, after this one task, the intimidation factor was completely gone. It was perhaps a mixture of knowing that “my colleagues have my back” and thinking, “I’ve already made a clown of myself, it’s only upwards from here”, but whatever it was, it made me more proactive, willing to participate in discussions, open about the issues I encounter and overall more likely to contribute.

It might sound wrong to set someone up for failure, but if you do it carefully, while managing your response and being confident that your team’s culture handles mistakes gracefully, then perhaps it’s OK to gently probe for your new employee’s limits and let them fail in a controlled environment.

Step 3: Let them work

At one point, my team decided they wanted to try the build automation tool Gradle. The problem was none of us really knew Gradle. We had a bunch of mostly working scripts that were transplanted from Maven (our go-to build tool), but we wanted to redo them the right way. Someone had to do the research, and that ended up being me.

I was given free rein to hack, slash and realign our build scripts. It was scary, but also incredibly empowering. Honestly, what a great way to tell your new coworker, “we would all have to learn this new thing from scratch, and we trust you’re just as intelligent as any of us.” Not only it promotes learning and accountability, but it also works the other angle: making the team accept the new person. After all, I had valuable knowledge (which I promptly shared with others – focusing on skill transfers is another amazing aspect of my company). For a brief moment, I was “the Gradle guy”, and that gave me confidence and an excuse to take stronger positions during meetings. The funniest part? We decided not to continue with Gradle for unrelated reasons, so all my scripts are completely gone from the project now – but the confidence remained.

The lesson here is that freedom and trust will help your junior spread their wings. It’s your job as a leader to ensure everyone has the resources and assistance they need, but don’t fall into the trap of micromanagement. You can’t expect someone to “take ownership” if they don’t own the thing in the first place, so let your junior be responsible for their task, approach and their own development.

Step 4: Get your team to socialize

I might’ve fooled you into thinking that this article is about coding. It’s not. It’s about soft skills and team building. Looking back, I think the biggest difference between “me when I got the job” and “me now” is not in the way I write code, but in my understanding of project goals and the resources (most importantly, human resources) that are available to me.

Your junior probably knows how to program (after all, they likely went through a multi-step recruitment process to prove that). The reason they aren’t effective yet is because they don’t know what to do, they feel intimidated, can’t find their way in your business domain and/or find it hard to navigate a legacy Java 6 codebase that could have been maintained better. All of these problems can be solved by talking with your colleagues (maybe except the last one – that one is hopeless). And the best way to create an environment where people feel it’s natural to talk to and help each other? Take them to a pub.

Don’t rely on contrived, organized “team building exercises”. The only thing a corporate team building exercise fosters is disdain for such exercises. Instead, our team meets for drinks and ribs several times a year. Those are simple, informal gatherings of just the core team. It’s the type of meeting I’d go to with the people I like, and perhaps that’s why I found it easier to simply talk to my colleagues and befriend them. And, since we like each other, we help each other. It’s natural to do so.

In the past, I’ve had situations where I helped someone begrudgingly because I perceived that as an extra chore on top of my own work (I was “doing somebody else’s job”). I don’t feel that way in my current job, because I enjoy working with my teammates and have good reasons to expect reciprocity. Also, I don’t feel bad asking for help, because I have my own expertise to offer in return (I used to be “the Gradle guy”, now I’m “the Redux guy” and so on).

Junior software engineers will start contributing fast in the right environment

Yes, there’s still a lot for me to learn (the first thing that comes to my mind when I hear “Kafka” is still the novelist from Prague), but it’s been less than a year since I first heard of Spring’s existence, and I’ve already contributed production-ready code and proposed meaningful refactors, not to mention that I also got some experience with TypeScript and React and even managed to squeeze in a bit of Kotlin.

I’m not trying to brag – every single junior on the team made amazing, measurable progress and has a history of successfully delivering both front-end and back-end features. That risky period when your team’s productivity goes down a few percents due to having to onboard new team members? It took a month at most. I was ready to write code on my own before I even got a security clearance from our client.

The practices described in this article reduce risk, improve the value-cost ratio of your new employees and improve the onboarding experience – for everyone involved. If you’re looking to collaborate with dedicated development teams that contribute from day one and take ownership at all levels of seniority, get in touch via this form.