How long should a tech test take to complete?

Everyone has an opinion on this topic, with answers ranging from a few minutes to a few days.

We’ve even heard horror stories of teams saying “Well, if they want to work here, they’ll spend their weekend working on our tech assessment” (hint: No they won’t)

Let’s explore how long a technical assessment should take from a couple of different angles.

Before we jump in we should be clear about a few things, there is a difference between the time a candidate is expected to work on the challenge and how long they have to complete it.

It is possible to have a challenge that gives the candidate a week to complete it, but they should only spend a few hours actually working on it, we call these open ended.

Alternatively you can have challenges that are time capped to the actual time the candidate should spend working on their submission. There are pros and cons to of each of these.

Be guided by the data

Most of Geektastic’s library of technical assessments take between 1 hour to 3 hours to complete. We also migrate our clients’ own challenges to Geektastic, these have a similar range.

We manage a mixture of time capped code challenges (where the clock is set to the time the candidate can spend on the challenge) and open ended (where the candidate is given say 5 days to complete the challenge but are advised to spend only 2-3 hours actually working on it).

Top Tip: If you are looking to increase the completion rates of your technical assessments, make them time capped not open ended.

We’ve looked at the data from our platform and measured average completion rates of challenges to compare those that are time capped and those that were opened ended.

• Time capped challenges had a 12% increase in submissions.
• That means 12% more candidates went through the process.

When you think about how much time and effort you put into sourcing candidates, getting 12% more through your process makes a huge difference.

Overall we see >70% of candidates proceed through our assessment process. A well honed process should deliver over 85% of candidates. How does this compare to your current process?

Why do time capped challenges work better?

From our tracking we can see that candidates start an open ended challenge but don’t submit their solution, whereas with a time capped challenge they block out the prescribed time and submit just before the clock stops (in most cases - you do need a back up plan if they miss the deadline).

With open ended challenges candidates start the challenge and leave it until later in the week to complete it. During that time any number of things can happen.

• The candidate starts and finishes a time capped technical assessment with another team
• They get an offer from another hiring team who moved faster
• They get frustrated continually refactoring and optimising their solution
• They worry that other candidates will have spent longer than the prescribed time and want to perform better, so they continue to work past the suggested time.
• Time capped challenges allow you to fairly compare apples with apples as candidates have all spent the same amount of time on their solution. If one candidate has spent 2 hours and the other has spent 5, then the submissions are hard to compare.
• Time capped challenges allow you to calibrate a challenge. You don’t want a challenge that’s so difficult or the technical bar is set so high that nobody passes, likewise you don’t want a challenge that lets too many candidates through to the final stages of your process, defeating the object of having the challenge in the first place.

The team that moves candidates through their process fastest, with the least friction, **hires the best candidates. **

So come on, how long should they be?

We looked at the data and combined that with candidate feedback.

Anything less than 1 hour doesn’t provide enough insight and means you still need to do more assessments, lengthening the process and frustrating candidates. Anything longer than 3 hours puts candidates off. They feel that you are asking too much from them.

Our 2 hour time capped challenges have the highest rate of completion.

When asked, candidates felt this is a reasonable amount of time to ask to allow them to show off their skills whilst not needing to spend too long on the challenge itself.

Here are a few more things to bear in mind:

• Provide prerequisites to the candidate before they start the challenge that describe what they need set up to start the challenge and a very high level description of what the assessment will involve. You don’t want the candidate starting the challenge and then realising they need to download new tools or software versions.
• Provide a little extra time to make sure the challenge is achievable within the time frame. You don’t want the candidate freaking out because they think it’s an impossible task.
• Reduce the number of steps in your process. Please don’t try and ‘do a Google’ and implement a 10 step hiring process. Engineers are in such high demand they are not going to engage in your process if it has too many steps.
• An ideal process looks like this
  • Initial call (this used to be a called a phone ‘screen’, but the reality is this is a phone ‘sell’, this is where you find out about the candidate and what they are looking for and for you to ‘sell’ the team, the tech, the product, the vision etc
  • Take-Home coding challenge or F2F (or rather zoom call as everyone is hiring remote now, aren’t they?) pair programming / technical assessment. Make sure you are getting the results back to the candidate in less than 24 hours or you will risk missing the opportunity (if you are struggling with this Geektastic can help - we review all code challenge submissions in less than 24 hours)
  • Final meet the team interview; deep dive in their technical assessment, allow the candidate to meet as many of the team as possible
  • Make your offer or provide detailed feedback why it didn’t work out.

For more tips on creating a code challenge please take a look at our blog post by Andy Davis here

##