How to Ensure More Candidates Take Your Coding Challenges

It’s a candidate’s market and hiring good software engineers is harder than ever.

Once you have spent ages searching for and engaging with the perfect candidate the last thing you want to do is to put them off with your hiring process. You want to make it as short and frictionless as possible, but at the same time engage the candidate so they feel enthusiastic about the tech and the team they will be working with.

This is why many firms opt for a coding test in the early stages of the software engineering interview process. The softer skills based interviews are so valuable but at the same time you need to understand whether the candidate is the right level technically to be let loose on your code base. The problem is, so many software engineers hate 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.