The broken state of the software developer recruitment process

In my many years working within dev teams, I’ve been a part of roughly 40+ interviews, both as an interviewer and interviewee. Although there are many things I’ve seen done well, there are also many issues I feel are shared across most development teams. This is a list of what I think are the major sins found in software dev recruitment.
A general lack of professionalism
Now, I understand that dev teams want their environment to be laid back and easy going, and that they want to come across as such in interviews, yet I get the impression many think it is not possible to do so whilst maintaining a basic sense of professionalism.
Too often I have found an interviewer has not looked at my CV, or is making up their questions as the interview goes on — this can be incredibly disheartening for a candidate, and reflects poorly both on the team and the company. Other typical behaviours include the interviewer checking their phone, making an inappropriate / inside joke, jumping back and forth between topics, or taking on an overtly casual tone.
Doing some basic preparation can go a long way in easing the candidates nerves, helping the interview go smoothly, and making the team come across in a positive light.
A lack of training
This is a little bit of a follow on from the previous point, and I presume only those who have been on the other side of the curtain are aware of it. Simply put, nobody is given interview training. In my experience, dev interviewers are shortlisted based off their tech skills and experience, and — that’s really it. No one is trained on how to carry out interviews, how the team wants to be portrayed, or how to be inclusive of all genders, ethnicities, religions, and sexual orientations.
I’ve frequently been put into interviews not even knowing if I’m interviewing for a junior, mid, or senior level developer. No discussion takes place on what kind of employee or developer is being looked for, or the structure and content of interviews — it is very much “wing it as you go”.
As above, some pre interview discussions and training would not only go a long way in benefiting the team and the candidate, but also the company itself — A candidate who has a poor interview experience, is naturally going to think poorly of the company too. It also just might help us to diversify the software development workforce beyond 25–40 yr old straight males.
Long, long, long face to face interviews
I get the feeling that a few years ago the development world became aware that “cool” tech companies carried out long face to face interviews, and so everyone thought “we should do that too!”.
The problem I have with this is that a lot of devs I know are “introverts” (myself included), so expecting them to engage with 4–10 people for 3+ hours, whilst showcasing their best side, and technically excelling, is unrealistic, and often alienates good quality candidates. This is especially true when interviewers are unprofessional, unprepared, or any of the things I mention here. Just split the interview into stages like every other trade.
The whiteboard exercise
Again, I feel this is something dev teams do because they read that another “cool” dev team does it. An arbitrary problem is put to the candidate, who is given a few seconds to think of the solution. The candidate then has to write their solution on a white board, whilst explaining to people sat behind them what they are thinking, whilst also taking questions, whilst also making sure their solution covers edge cases — this, whilst under the pressures and nerves that come with interviewing and presenting to an audience.
What is being tested here is not someone’s software development ability, but their ability to solve impractical algorithmic problems, in a way few devs actually do, whilst under an intense mount of pressure and attention. From my experience, pair programming on a real life task is a much better way of understanding tech ability, and also takes away that spotlight and pressure.
The obsession with “culture fit”
Now, I am well aware people do not want to hire unprofessional employees, or self serving egos — and unfortunately there are a lot of these in the dev world — but really, this is what reference checks and probation periods are for. Many dev teams appear happy rejecting good developers because they didn’t give a very particular answer, to a very particular “culture fit” question. Ironically, many of these culture fit fanatical dev teams will never bothering to do basic thing like check references, or verify the experience that the candidate claims to have is real.
I am yet to come across a dev team which has a culture as brilliant, sacred, and pure as the team appears to think it is, and getting over this often misguided obsession with “team fit”, might again also help us to diverse dev teams beyond 25–40 yr old straight males.
Interviewing by trends
This is something I see less and less these days, but I still think it is worth highlighting. I often see teams institutionally rejecting good devs because the dev didn’t have experience with the “latest” cool, new, edgy, framework or library — my experiences might be skewed because I am a JS dev, and fellow devs will know the stereotypes about us.
The thing with trends is, they come and go — the lib that is hot today, could be replaced tomorrow. If a developer hasn’t tried that cool new library, it doesn’t necessarily mean they don’t take their career seriously, or aren’t a good dev, it might just indicate they are more interested in sustaining long term dev skills over arbitrary lib “exposure”. Development skills always trump specific library experience in my opinion.
Irrelevant technical questions
I was once asked how to work out the shortest distance on a line to a specific point — as noted above, I’m a front end developer. Maybe others will disagree, but I don’t think knowing the above answer makes me a better FE developer. To be frank, if similar problems to the above ever came up, I feel the majority of devs would just Google it.
I frequently find interviewers ask technical questions that have less to do with actual software development ability, and more to do with whether the candidate reads specific blogs, or has exposure to a specific development pipeline. Worst is when the candidate is asked outdated questions (note FE devs: almost no one cares about AMD require anymore, seriously), often indicating that either the interview questions are old, or worst, that the companies tech stack is. Dev teams should try to filter questions through the queries “does this problem actually occur in our dev work?” and “would I just Google this?”.
So that’s it, my list of the major sins of software development recruitment. I feel the software development world is yet to understand the massive amount of time and energy it takes to create and execute a professional, effective, and robust recruitment process, and dev teams — often due to time constraints — are caught mimicking trends and winging it rather than putting one into place. In the long run though, this will only benefit the software development world, it’s candidates, and dev teams themselves.
Thoughts, opinions, and suggestions are welcome.
