So what exactly is a junior software engineer?

Recently we’ve talked to a lot of junior and graduate software engineering candidates. We had a crop of awesome interns over the summer (one of whom we hired). We’ve also hired some excellent junior software engineers to round out the team over the last twelve months. We do screening calls with almost all of the candidates and we’ve begun to notice a pattern. Almost every candidate asks us, in some form or fashion, to define what we consider “junior”.

Initially we were quite confused by this as the definition, at least to us, seemed simple:

An entry-level engineer with limited exposure to development and development practice who will need strong mentoring and support to grow their skills.

Digging into this however with some of the candidates we’ve heard variations of the same feedback: that the definition of “junior” is both highly fluid and often actually not very “junior” at all.

So I started doing some research into job ads that claimed to be seeking junior or graduate software engineers. Overall, I reviewed 60 Junior Engineer job ads.¹ What I found was, in my view, downright ridiculous.²

The first piece of silliness was the frequent requirement³ of a Computer Science⁴ degree (“or a degree in a related technical field”). This wasn’t just a preferred criteria of many roles, it was a mandatory requirement. A lot of the job roles with a requirement for a Bachelor’s degree in CS also had a “Masters degree in CS or related technical field” as a preferred criteria.

So automatically any of those ads eliminate anyone who doesn’t have an appropriate degree. Which likely eliminates almost anyone who got their engineering start at a code school or academy. Or who is self-taught. Or whose path to engineering was via another discipline.⁵ That many of these candidates with non-CS backgrounds tend to be diverse too is also a big concern.

My first thought here was towards the endless stream of folks claiming technology has a pipeline problem. Well, in this instance, it appears it does have a pipeline problem: the pipe is so narrow that only a proportion of candidates can fit through it.

The next piece of ridiculousness was the amount of development experience most ads required. Of the 60 roles I examined there were 48 that listed experience requirements in years. Of those 48 roles, 23 of them expected the candidate to have 2+ years experience. That means 48% of the roles that cited years of experience as a requirement expected at least 2 years of experience (As a percentage of all 60 roles that is 38%!) Most of the other roles with years of experience requirements had ranges, most heavily featured was “1-3 years of experience”.

Where exactly do most “junior” candidates get two years of relevant work experience if 38% of jobs require they already have 2+ years of experience? I get a distinct feeling of Catch-22 in the whole situation. A lot of candidates we’ve talked to, irrelevant of their background being a CS degree or a code school, don’t even have one years experience of being an engineer.⁶

Beyond years of experience most of the roles required specific skills. Many of them required experience in the company’s core technology stack. This was usually described as “development or programming experience in x+1 languages” or “experience with x+1 technologies”. A couple of absolute gems included:

Experience in network programming and developing & designing large software systems.

And:

Solid experience with either Unix/Linux or Windows environments, distributed systems, machine learning, and the TCP/IP network stack.

WTF? There might be a junior or graduate engineer with experience (for some definition of experience) in network programming and developing and designing large software systems. Might be. There might also be unicorns. Similarly I’ve talked to some junior engineers who could give me the academic definition of a distributed system. I don’t know many (any?) who have “solid” experience with them. Some days I don’t think I have solid experience with distributed systems.

Either way I struggle to understand where junior candidates would get this sort of experience. I expect there might be some college graduates who have done one or more internships, probably with larger companies, who might have scraped the surface of these requirements? Again the pipeline’s width seems likely to severely limit the pool of potential candidates for these roles.

So why do companies list requirements (and preferences) for roles that only a very small number of junior candidates can match? I have a few vague hypotheses:⁷

1. The rose-colored glasses view of junior engineer life and experience. Many engineers (and/or managers) writing job descriptions and ads seem to have forgotten what it means to be a junior engineer.

2. Many organizations have an idea they’d like to hire a junior engineer and start the process by identifying the work they’d like that person to do. They base their list of requirements off that work and make the assumption that the candidate can hit the ground with that work on day one! Instead of seeing this work and the potential skills as an aspirational target.

3. Organizations are (consciously or unconsciously) aware of the potential investment in hiring a junior engineer and want to limit the cost. Both monetarily and in mentoring and training. By making the barrier to entry higher they are telling candidates either:

   Don’t apply unless you have these skills.

   Or:

   Don’t apply unless you’re prepared to lie about having these skills.

   Either way if you make it through and get hired and you have gaps in any of the areas we’ve specified then don’t expect help in closing them or make the assumption you’ll need to bootstrap that yourself.

Overall, I was left with the feeling that our industry no longer understands the definition of “junior”. I also think that our mistakes in, inability to, and even potentially disingenuous attempts to define “junior” are causing serious issues. Both for hiring and potentially for development too. A lot of this behavior seems to undermine the value and limit the potential exercise of mentoring and growth in organizations.

I think our path to fixing this requires quite a lot of changes in the way we think about recruiting. These are some rough ideas:

• Be honest in job ads. If someone requires more than entry-level skills in an engineering role then don’t call that role a “junior” role.
• If you are looking for a junior candidate, make job ads more broad and less constrained by “years of experience”, background or specific frameworks and languages. Try to move assessment of experience and skills to practical tests like code challenges.
• Stop privileging CS degrees as the only path to an engineering career.
• If you do have a big ask for experience and skills then balance those between required and preferred. Talk specifically about mentoring, on-boarding and growth and how candidates with gaps in those skills will be successful if hired.
• Emphasize the aspirational opportunities for an junior engineer and the organization’s commitment to building their skills.

I think most of these ideas are fairly simple and don’t require a lot of effort, if you’re serious about hiring and growing junior engineers. We’ve already adopted many of these ideas and approaches and I think we’ve gotten a more eclectic and diverse pool of candidates as a result. I’d love to hear from folks about their experiences and whether they have other ideas.

P.S. I’ve got to thank Adria Richards for sparking the idea for this research and the resulting post.