There’s a sad running gag in our industry: “Looking for junior developer with five years of experience.” (Examples: 2019, 2020, 2021.)

You can tell the contradiction: We can have close to no expectations of junior or, generally speaking, young and inexperienced developers.

Any expectations we do set change the profile we’re hiring for. To stick with the popular example, if we’re looking for someone with five years of experience, we’re looking for a medior. Not a junior. If we keep these expectations up insisting on hiring a junior, a working student, or even an intern, it gets ridiculous (and exploitative).

Consequences of Unrealistic Expectations

While we know of our thirst for experienced developers and see that thirst trickle down to entry roles, we may not consider what unrealistic expectations mean for young and inexperienced developers.

We show disrespect. Asking someone to meet a standard they cannot meet is not showing appreciation for who they are, what they bring to the table, or what else they have accomplished.

We evade our responsibility to mentor and coach. By suggesting a candidate knows everything, it may be argued that we’re playing a cheap trick, acting like we don’t need to train them anymore. The candidate may see through that, but we may fool ourselves in a way that hurts us more than we think, because evading that responsibility also evades the respective growth.

We put undue pressure on candidates. Unrealistic expectations make for pressure. A young or inexperienced developer already has enough of that—after all, they’re just trying to get a foot in the door, to start their (new) career. This is hard. Add brazen requirements and it gets worse.

We set candidates up for failure. When—unintentionally or not—we’re not up to our own responsibility and instead put pressure on young and inexperienced developers, we set them up for failure. We make it harder for them to enter the field, and we make it harder for them to acclimate and thrive in the field.

Healthier Hiring

What we can do instead is to lower the expectations on young and inexperienced developers—and to raise the expectations on the mentoring and coaching of young and inexperienced developers.

There can be several reasons for hiring someone young or inexperienced, but we must be far past doing so in order to take advantage of them. This is a terrible reason, and those motivated by it are fit for neither hiring nor leading.

The best reasons include that you want to give to the candidate and the community, and that you hire because you deem it part of your mission to train and nurture new talent.

One Approach

I’m still tweaking my own management and leadership philosophy. But here’s my thinking around young and inexperienced developers:

• In general, there’s a hybrid goal for each engineering team to complete work, do good work, and drive work forward; and to do so in (and contribute to) a healthy and diverse work environment and culture.
• Young and inexperienced developers cannot immediately contribute to the first part of the goal, but are already one key for a healthy environment and culture. They may be so important for that, that in some team constellations, a junior developer could make the team more effective than a senior developer, just because that may avoid some sort of “seniority mono-culture.”
• When hiring young and inexperienced developers, one fair condition is that they have some early link to the field—like, they’re studying computer science, or they went through a development bootcamp, or they’re running some technical projects.
• More important, then, are soft skills: Is the person awake, are they motivated, are they a good culture fit?
• The rest, then, is the manager’s and the team’s responsibility: They are now responsible for mentoring, training, and guiding the new team member so that they can be successful (to the extent that the new member accepts their own responsibility).

❧ Hiring juniors, hiring young as well as inexperienced developers is important and beautiful. But the challenge is training and mentoring them, and that responsibility should stay with us, and not be loaded off on new talent by setting unrealistic expectations. Let’s put the pressure on us, the experienced developers and managers, and reduce the pressure on new peers. That’s much better for everyone.