Should you list specific languages in your developer job description?

Published by:
Hew Ingram
March 27, 2020
min read

In a recent webinar looking at “writing the perfect job description” one attendee asked a super interesting and highly relevant question:

For Engineering or specific type roles, what are recommendations on how we can add skills/languages needed in a more detailed way?

You can watch the recording of our webinar here.

Lots of job adverts for developers end up looking like a long shopping list of buzzy tech words. Some keep things light, “experience working with an OOP language” where others are weirdly specific “experience in ES6+” (ES6 is a specific release of Javascript from 2016).

In a world where we know that, given a list of requirements for a job, men will tend to apply when they meet 60% of requirements whereas women only when they meet 90%+, what’s the right approach for a technical job ad?

In my opinion there are a couple of things to consider...

What skills do you actually need?

Roles that are very technical are often seen as requiring “hard” skills and anyone without those specific hard skills is often totally overlooked.

Tidelift did a report (The 2019 Tidelift managed open-source survey) that looked at “how developers spend their time”. This found that only 32% of a developer's time is spent writing new code or improving existing code. To me, this indicates quite strongly that skills such as a particular language are only part of the picture of what being a developer is. Most development teams these days use some kind of agile delivery framework (such as Scrum) - these often rely wholeheartedly on teamwork rather than individual contribution and so “softer” skills (a term I hate, we generally call them team skills) are absolutely vital to a developer in a development team.

So, are technical skills (such as language specifics) the only important thing? Definitely not.

Yeah, I get that, but my applicants also definitely need to have been writing React for 5 years because we use React!

Now the question of "does a developer need to match up to the specific engineering stack" is a slightly different one.

Let's start with looking at it from the candidates point of view: In the 2019 Stack Overflow survey 54% of respondents cite “languages, frameworks, and other technologies I’d be working with” as being the most important factor in job searching. Annoyingly they didn’t delve deeper into whether this means “I want to work with React because I’ve spent 5 years writing React” or “I want to work with React because I’ve spent 5 years using Angular” - my hypothesis (and definitely the feeling among developers I know) is that continuous learning is a big part of people choosing this as their top motivation in job hunting. This means that ensuring candidates perfectly match your tech stack might actually be counterproductive when trying to attract talent.

Different languages are generally only syntactically different (aside from large paradigm changes like OOP vs functional) - and so actually picking up a new language isn’t particularly tricky (I used to work on a lot of PHP and was completely new to it as a language which just meant I spent time googling for methods that matched what I was used to in Javascript or python).

There's even an argument that people fresh to a language bring patterns and behaviours into their code that aren’t common in the team they’re entering but are great (and these are patterns they’ve picked up in other languages).

And then there’s the fact that languages change rapidly. I really wouldn’t hire a Javascript developer with 10 years experience on that alone because Javascript was wildly different 10 years ago - the way people were writing the language was very non-functional and in 2016 a bunch of functional methods (pinched from other languages) were ported into Javascript and all of a sudden a Javascript developer with some experience in a functional language became really handy.

I get all this academically but...

Ok, before you go on with your length of technical requirements... hear me out - here are two anecdotal bits of evidence that being more lax on the requirements fronts can either help or at least not hinder:

Nested, a proptech company, uses Erlang and Elixir extensively… a language most developers have never touched (and in fact a whole paradigm of programming few developers have never touched!) and so part of their hiring process is around finding analytical thinking and problem solving, safe in the knowledge that developers will be able to switch language easily.

Here at Applied one of our developers, Evelyn, was predominantly, a C# developer with only a few months of using Javascript before applying to us (and that was mostly bug fixing in a previous role). But what was obvious was that she thought through problems in a logical way, designed for resilience (and all of the things we look for in technical design tasks) and knew how to tackle writing code. We did a pairing interview (using Javascript and Vue) and the only real difference is that she had to google some function names and ask some sensible questions about how Vue (which she’d never used) worked.

So do I think experience with specific languages is vital in dev hiring? Not at all. Do I list some details of our tech stack in job ads? Yeah I do, but they’re never a requirement. Something like StackShare is a really great place for sharing your companies tech stack + link people to (mostly so they can see the tech they’ll get to learn and work with!).

If you want to learn more about how we hire developers at Applied, I broke down our entire process in this blog post.

Our next webinar is coming on the 8th April. We'll be hosting a a crash course in smarter, fairer interviewing. In the meantime, why not take a look at our  job description analysis tool? Our tool offers insights into how you can appeal to a diverse range of talented candidates.