How to stop scaring off your candidates with your code challenges
Hiring the right employees is critical to the success of any business. It is also an incredibly time-consuming process in what is, more often than not, a time-sensitive situation. This is never more true than when hiring software engineers. Developer interviews can often consist of several stages, so filtering out any candidates who won’t make the cut as early as possible is all-important in ensuring enough time is spent on the ones who do.
This is why many firms opt for a coding test in the early stages of the software engineering interview process. The fluffier interview stuff is nice and can be valuable, but ultimately it always, or should always, come down to whether the engineer can write the code. The problem is, so many software engineers hate those technical tests. And, to be fair, there are some very good reasons why:
1) No level playing field
So, you’re an experienced developer looking for a new role and suddenly you’re bombarded with 5 or 6 requests to do code challenges with no defined time limit: “get it back to us in your own time - next week is fine…”. So effectively it is something you could easily spend 6-8 hours or more completing. Most software engineers realise that any piece of software is never complete. It can always be improved. How do you know how long to give to a challenge like that? Maybe you’ll be up against a developer who is not as talented as you but who has much more time to spend taking the test.
That’s not to say a timed code challenge is necessarily the easy answer either. Andy Davis of Tenkaisolutions, a development and agile specialist with over 15 years in the industry, finds timed coding challenges can accidentally promote poor quality: “I don’t mind a timed coding challenge but it is something that makes me rush, and if I rush then I make mistakes.
“Often you’re expected to be all set up and ready to work on code, but actually this setup time is time that you need to contribute to doing the test. I actually know plenty of great developers who don’t have a dev environment setup at home - especially true in the .NET world where historically a development environment is really expensive,” he says.
It’s always good practice to make sure that your candidates have the basic development environment setup before their challenge timer starts. Let them know what they need to have installed and running - and in generally keep these pre-requisites to a minimum.
2) Old or poorly constructed coding challenges
It’s surprising how many times we’ve heard software engineers tell us about being faced with ancient or poorly conceived code challenges that have very little to do with the day-to-day role they’re applying for. A challenge that’s been around for years: “it’s the one we always use” - but no one ever questions that as roles, responsibilities and technologies within the company change and evolve. What’s the point in spending hours completing a test that will provide almost no insight into the skills you’ll need to make a success of the actual role?
The code challenge that’s set is a reflection of the company and the current development team. If the challenge is poor that’s a poor reflection on the company. If the instructions are unclear or ambiguous or show that no one in the current team has actually thought it through from the perspective of the person trying to complete the challenge in two hours then that reflects badly and the candidate’s perception of that development team is going to be tarnished.
3) Reviews that are performed by a machine
Code challenges that are marked as a pass or fail by a machine allow for no benefit of the doubt. Often the candidate’s approach to solving a problem is just as illuminating as the solution itself. As every developer knows there are always ten different ways to solve a problem and some of those approaches will have different strengths and weaknesses. That’s why challenges assessed by a human will always seem more reasonable to a software engineer than those that work from a score calculated by an algorithm.
4) Code challenges are notoriously difficult to send over email
This one is really straightforward but a surprisingly common problem. Code challenges compressed into zip files often get stripped out by mail servers, or flagged as a “security risk”. This is one of the key reasons why so few of the code challenges that are sent out by employers get completed – the software engineer didn’t know it was there in the first place.
At Geektastic, we spend a lot of time talking to recruiters as well as our global network of skilled developers. Like Robin Beattie, Director of technology recruiter Mortimer Spinks who knows all too well the problems in persuading developers to take code challenges: “We are increasingly experiencing a difficult scenario between the client’s desire for all candidates to be tested and candidates (understandably) pushing back on doing multiple challenges, when each of those challenges can take 3-4 hours or more to complete,“ he says.
Beattie adds that sometimes as little as 10% of contractors actually take the code challenges resulting in both clients and candidates missing out on a perfect match.
While we’re not bold enough at Geektastic to claim we’ve found a solution to the whole problem, we do think we’ve come up with something that works a lot better.
The answer - Code challenges that are tailored to the specific technologies required for the role, that allow the software engineer to choose whether to complete it as an open-ended (“next week…”) or shorter time-constrained test. The challenges are created by our developer network and reviewed by them. No robots, real humans who have taken these challenges themselves and have produced reference or benchmark solutions. All challenges are handled within the Geektastic platform, so there is no need for email file attachments.
Why don’t you try one of our peer reviewed Geektastic code challenges? Register now
Would you like to license a geektastic code challenge to analyse the key skills of your candidates? Register now
Geektastic also looking to provide a level of quality for the code challenges that will allow us to say to employers for example: “this candidate has already demonstrated their skills in Java and knows how to setup a Spring application. Here is their challenge submission with the reviewers comments and appraisal. We don’t think that there is much need for you to have them complete your own Java / Spring challenge which tests similar skills.”. We think this will be a strong benefit for software engineers: complete a couple of Geektastic challenges and that will qualify from a technical perspective for multiple roles.
Our code challenges evaluate both overall technical ability and specific software skill sets. This allows employers to filter their final list of candidates quickly, eliminating hours of time wasted in evaluating CVs and reviewing code challenges. Not quite a revolution then, but definitely a good start.