A growing number of companies are using technical coding tests as a key part of interviewing new developers. However, in our experience the number of developers that fail these tests greatly outweigh the number who pass them.
Does this make them bad developers?
The answer is generally no, it’s all to do with the technical test.
To explain this, the first step is to look at the evolution of ‘The Modern Developer’ and the path they take to get where they are. Generally speaking, there are two routes: A Computer Science Degree OR self-taught engineers, who start by hacking code together and discovering a passion for developing – this is particularly prevalent in the Open Source space!
If we look at the evolution of the Computer Science Degree – back 5+ years, they were heavily mathematical, involving lots of algorithmic problems and calculus. The developers that completed these degrees are most likely the tech leaders of today and the ones setting the technical tests. Based on their studies, they can solve algorithmic problems (and did so very well when they were at university). They are likely to bring these same expectations of the junior developers they interview.
Now, think about the modern Computer Science Degree. It’s modular, and students can choose where they put their focus - meaning algorithmic modules are often skipped over and more emphasis is put on OOP, mobile, cross platform and other technical queries. These developers have rarely (if ever) had to use their algorithmic knowledge, so will not pass these algorithmic coding tests. On the same token, the self-taught developers are similarly unlikely to have used algorithms in their at-home learning.
Setting this type of slightly dated, algorithmic, technical coding test for a contemporary developer can be detrimental to the success of the interview and not necessarily reflect the quality of applicant.
So, what should be in a technical test?
Here at Talent Point we are making roles in line with the market and focus on repeatable hiring, a key part of this is changing interview processes and making managers aware of how to interview and get the best out of developers by focusing on their skills and talents. We suggest that companies try and set a real-life coding test that will mirror a problem they will solve on the job, as this is what good developers do best; problem solve.
There are two ways to work this kind of test into your process:
1. A code review/refactor – bring a piece of code that was written by one of the development team the day prior and ask the interviewee to perform a code review and refactor the code. This shows what practices the developer enforces, as well as being a great ‘one size fits all’ from mid-level – senior developers and requires minimal preparation for the interviewer!
2. Deconstruct a typical daily problem - work backwards on a task to demonstrate these skills and set a real-life challenge that they can build from scratch.
An example of this method of testing is proving much more effective. Recently we were working with a customer that was finding it difficult to hire software engineers, all the developers we were putting forward were excelling in answering questions around project work and core engineering principles but fell short when faced with the technical test. After some feedback from both sides it quickly became obvious that the test being set was overly algorithmic and not reflective of real life. We encouraged change on the technical test, shifting away from being based on algorithms. Interviewees are now presented with a problem around file transfers, much more common place within the business.
We then invited the developers who failed the initial test back in to the business to try the new test… They passed with flying colours and have been successfully hired by the business in question.
Moral of the story – make your technical test an enabler to show off a developer’s talent, not an inhibitor!
If you would like advice on how to change your tech hiring for the better, get in touch!