Stop requiring specific technology experience for senior-plus engineers
A conversation I’ve had (too) many times in our industry:
You: “I’m looking to hire a senior engineer. Know anyone good?”
Me: “Oh great, I know some good people! How about
You: “They won’t do. We need someone with at least
You: “They need to be able to get up to speed quickly.”
There’s many assumptions being made here that may or may not apply in your organisation:
- having written
$Xyears means new hires will be able to get up to speed with your codebase using
$TECHNOLOGYbecause they won’t have to learn
$TECHNOLOGYon the job
- all your existing use of
$TECHNOLOGYis so perfectly idiomatic that it will be trivial for anyone with
$Xyears experience in
$TECHNOLOGYto understand the code
- the main blocker in getting up to speed quickly will be learning
$TECHNOLOGYrather than learning your version control system, deployment system, company engineering culture, etc.
- there is a sufficient supply of engineers with at least
$TECHNOLOGYthat will want to work at your organisation for the compensation you’re willing to pay and loosening these constraints will not get you a better hire
- the short-term optimisation for new hires getting up to speed quickly will be a good decision in the medium/long-term
You also may or may not have thought about the following:
- much of the job of a senior-plus engineer involves tasks unrelated to writing
$TECHNOLOGYe.g. databases, on-call, deployment, mentoring, breaking down issues, collaborating with management/product/design/sales etc.
- engineers who already have experience in more than one
$TECHNOLOGYcan often pick up new ones extremely quickly
- experience with more than one
$TECHNOLOGYparadigms can often make engineer better at writing all languages
- your choice of
$TECHNOLOGYmay not be the best fit for the problem and an engineer with experience in other languages may help you consider future alternatives
- you may not be using
$TECHNOLOGYin the medium/long-term
$TECHNOLOGYmay not be something that many people have
$Xyears experience of (but are willing to learn)
In my experience, the combination of those assumptions and not thinking about all the above (and more!) mean that I consider it to be an anti-pattern to require experience with a specific technology from engineers. You can factor it into a hiring decision: given two otherwise identical candidates the one with more experience in this language may be more desirable.
If you reword your job advertisements to remove this
$TECHNOLOGY as a “requirement” and replace it with a “desirable” (or just mention you use it) you will find yourself able to get more, better candidates into your hiring pipeline (particularly from underrepresented groups in technology that will often not bother to apply when they don’t meet “requirements”).
This may require changing your interview process. If the majority (or entirety) of your process assumes working familiarity in a given language and you expect the candidate to be able to write that language without any help: the candidate and interviewer are going to have a terrible experience. Ideally, your process allows the candidate to bring a language they are comfortable with and/or is an “open book” pairing process on the technology you use internally. Additionally, the more experienced the candidate or more senior the position: the more of the interview process should be dedicated to communication, engineering best practises, architecture, etc. rather than just programming.
This can be a hard adjustment to make but it’s one the best engineering interviewers made years ago (and you can too).
By “a senior-plus experience” I mean e.g. senior, staff, principal engineers etc. Never heard of staff or principal engineers? Check out my “What is a Staff (or Staff-Plus or Principal) Engineer?” article .