Hiring Great Software Developers Is Really Hard, What We Learned This Month
Starting a company is a learning process, you have to challenge your own beliefs regularly and not be afraid to try new things. For a young company, hiring is critical, the wrong developers can cost not only money but months of time.
One decision I made quite early on was that I didn’t like code tests. As a developer, I had previously had a few poor experiences during interviews for developer jobs including people not explaining the problem they wanted me to solve, leaving out key details or challenges that are easy if you learned the trick (hint: they aren’t a real test). I thought they could be patronising and demoralising.
Though our CTO is an advocate of code testing, we agreed that on-the-spot code tests during an interview were not a natural way to code. So we did not do them, even though that fails the Joel Test: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/
This month has totally changed my perception of that, we’re in the process of hiring more developers at the moment but we had a time crunch. Generally, we follow the same process with all hires, initial call with the CTO, wider interview with three of us, meet the team and if everything works out then we’ll make an offer.
The challenge this time around is that we had four open roles, two frontend and two backend but on the frontend side neither our CTO nor I really knew the technology in depth. We had a time crunch, so our Agile Coach suggested that we try implementing a code test, his rationale is that it acts as an initial filter for candidates so we can focus our time on the best candidates and streamline the process.
We agreed on some key attributes of this code screening test:
- It should be short — no more than 30 minutes for the typical developer to solve. Their time is valuable as well.
- The tests should be simple. We were far more interested in considering a problem with a few edge cases and producing an accurate solution quickly. Rather than solving hard algorithmic challenges.
- The candidate should be able to complete it in their own time, without someone watching them. This is far closer to your normal development environment.
The results were nothing short of stunning and disappointing at the same time. More than 50% of the candidates we put through the test could not complete it in the time given, there was a direct inverse correlation between salary expectations and code results (more expensive candidates did worse!) and over 60% of the candidates did not meet the minimum standard.
It was a WTF moment, we were amazed at how poorly some of the developers were had received CVs/resumes from had performed. These were experienced developers who had listed React on their skills with previous professional experience using it, and they struggled with a basic code test in using it. Our CTO actually did the test himself and scored 100% with 20 minutes to spare, he has never professionally written React code. (For reference, we’re using Coderbyte as a service, so the test is one from their library)
So what would I suggest to a developer looking to get hired?
I think over the next few years, code testing services will become much more common, particularly if other organisations have similar results to us.
In my view it is important to not oversell your skills in a particular area, eventually, it will be found out and lead to bad feelings. When we’re hiring through recruiters it also means that we’re paying a recruitment fee which can be £10k+, and we’re relying also on the recruiter to send us good candidates. In some cases, it is in their interest to oversell a little, but in the long run, it is better that we get excellent candidates so we give them repeat business.
We’re realistic but it is important for candidates to be realistic in their expectations. One thing that really stood out for us was the inverse correlation between capability and salary expectations, and I think there are two reasons for that:
- As a developer gains more experience and moves into a more senior position, they spend less time writing code and more time talking about writing code, that detachment from the code base may mean they are rusty when doing what should be a simple test of skills.
- Additionally, it may have meant that in some cases they didn’t take the code test seriously or commit the time to it. For us, that is a huge red flag. If you can’t commit your time to show off your skills during a recruitment process, maybe that same lack of commitment would manifest during daily work.
This is of course somewhat speculative, but I struggled to explain it any other way.
With all that said, here is what I would recommend to successfully be hired:
- Show off what you are really good at, commit the time and speak confidently and competently about the areas you are skilled at.
- Don’t be afraid to show some weakness, but demonstrate how you are addressing them and how we can support you.
- Show growth potential, we would much rather hire someone on an upward trend.
- Teach us something, if we learn something from you during an interview then we will remember you. You are demonstrating that you are adding value immediately.
Lastly, for employers, think about how to get the most out of an interview
Interview processes are a big commitment from both the candidate and the potential employer. So an employer should spend time thinking about their process and how it can be improved to get the best results for both the candidates and the employer.
We generally follow this process now:
- Initial code test
- Thirty-minute phone call with the CTO
- One hour interview with CEO, CTO and one developer
- One hour meeting with the development team, ideally with 30 minutes playing some kind of game
Through this process, we are evaluating technical capability, personal capability, growth potential and cultural fit with the company.
One thing that I like to do to get the most out of the one hour interview is to have a specific plan for something to talk through with the candidates. Depending on the topic, we may send it to them in advance to give them an opportunity to prepare. We think this is a great opportunity for both sides to learn, it gives the candidate insight into our day-to-day and the company and it gives us insight into their thought processes and a chance to learn from them.
In my view, interview processes are a significant time commitment from both sides, so it is imperative that employers give serious thought to getting the most out of the process. If an employer seems unprepared, it should be as big a warning sign to the candidate as an unprepared candidate should be to an employer.
Also if you’re interested in joining RazorSecure, send us a message via our website!
