Hiring Devs - Why you should consider Juniors

Post image
Photo by Polina Zimmerman from Pexels

When it comes to developer maturity, I heard many tech recruiters and decision-makers saying: “We should only hire senior devs.” This may be justified in some situations, projects, or teams, but I do not accept this statement as a general premise. In this blog post, I want to highlight the benefits that juniors can bring to the team and encourage you to find and foster new talent actively.

First, I would like to emphasize that developer maturity is extremely difficult to evaluate. I even wrote a blog post in this series about why I find the “senior” term in software development paradoxical:

Hiring Devs - The Seniority Paradox

The not so small Differences

I see a lot of added value in junior developers in addition to the challenges, but they are just as difficult to generalize. Therefore, I will first try to roughly point out some categorical differences between junior and senior developers and then detail individual ones.

Of course, these assumptions are purely based on personal experience and therefore not backed by relevant data.

Topic Senior Junior
Knowledge Has historic knowledge, which
might be outdated or wrong
Has recent knowledge which might be
incomplete or wrong
Leadership Need less leadership, but motivation Needs more leadership, but is
more likely to be intrinsically motivated
Mentoring Needs inspiration Needs training
Salary High Low
Social Often more for themselves, prefer
technical challenges over team effort
Oftem more social and team-driven
Fluctuation Likely to quit for a higher-paid job,
or to improve career
Likely to leave for a higher-paid job or
to learn something new


I have often caught myself thinking that seniors are generally better qualified than juniors. I found out that this is not true for several reasons:

It depends hugely on the tasks for which you are hiring a developer. To design software architecture, tinker with a UI, or implement CRUD controllers. Some tasks require academic and/or empirical knowledge, which can only be gained through time and experience. But by far, not all jobs of a developer require that. So you should ask yourself “for which task” you are looking for someone even before writing the job posting.

Often it takes more creativity than knowledge, and especially in fast-moving disciplines like software development, data science, etc., historical knowledge can even be a disadvantage. Primarily, the term “X years of experience with Y” is obsolete nowadays. Tendentially, 80% of this experience has already become irrelevant. In the worst case, without the candidate being aware of it. In this case, you may hire people who bring outdated knowledge to a team that makes wrong decisions based on it.

Last but not least, one should always consider the actuality of the knowledge, regardless of the candidate’s experience. While this is often difficult, IMO there is a tendency for juniors to have less in-depth but more current expertise in their field.

A different Approach

Most likely, every developer knows: Sometimes, you need a totally different approach, not only a better understanding of the matter. This is already summing it up precisely. Having a mix of experience people with empiric knowledge and curious ones with more current expertise makes your team way more efficient than having “only experts.” Sometimes, even a total senior finds a solution herself by explaining the matter to a junior, which happened to me personally on both sides of the dialogue.

Of course, leadership and mentoring approaches are highly personal and cannot be generalized by any means. Nevertheless, there seem to be differences depending on the experience of individuals. Having a good mix of seniority in a team can help you as a leader to have some of your tasks balanced or even taken away by team dynamics because people start to mentor each other.

One recent example I have seen is that a junior did a tech-talk about what he’s just learned, which inspired and transported more current/detailed knowledge to the group’s seniors.

Social Aspects

Of course, I can’t explain this precisely. However, I think that many not yet so experienced developers (have to) ask more questions and in this way also deal more with the team members and not only with the subject matter. Often conversations with other team members lead to mutual motivation even if they remain technical. Not only for the junior who learns something new but also for the counterpart who can successfully communicate his experience and knowledge.

This communication in the team is not as one-sided as simplified here, but I am also not a psychologist and therefore have no more profound knowledge of this matter.

Final Words

Last but not least, we counteract the extreme skills shortage in the industry by passing on the knowledge in our organizations and teams to the next generation of young talent (okay, it sounds very strange to say that in my 30s). I think that every company shares this commitment and can improve the often “self-made” shortage of skilled workers.

In my experience, almost all employees are happy to pass on knowledge and actively participate in mentoring juniors if they are given the opportunity. Hiring a junior can even provide variety in the team and new challenges for bogged down or bored seniors.

I was inspired to write this post by Manuela Brunner and her story. I wish you all the best for your future path.

You May Also Like

Hiring Devs - The Seniority Paradox

Hiring Devs - The Seniority Paradox

In IT, there is a paradox when it comes to job titles. Somewhere along the way, the practice of linking job titles to a candidate’s (desired) experience became established in large parts of the market. This then created the now famous and omnipresent job titles like “Senior Software Engineer”, “Professional DevOps Engineer”, etc. In this blog post, I would like to explain the paradox around these designations and how I use them in the course of the talent search…

How a Strong Type System Saves You Documentation, Tests, and Nerves

How a Strong Type System Saves You Documentation, Tests, and Nerves

I was recently inspired to finally write this post. Especially in weakly- or untyped languages, such as the JavaScript or PHP world, the added value of strict type systems is often not recognized. Instead, many discussions and comments revolve around the need for tests or code comments. Contrary to that, in the functional programming world, we leave such checks to the compiler. In this post I would like to give a short overview and explain how to use a strict type system for everyday checks instead of writing type checks, tests and documentation for it.