Hiring developers is not an easy task. I know - I've done the whole sifting through resumes thing, trying to work out who might be a good fit for your team before you invite them in for a conversation. Having that conversation is - arguably - the easier part. How do you validate the candidate actually has the knowledge and experience they claim to have?

The industry has come up with a number of different ways of doing this, from take-home technical tests or reviewing code previously written by the candidate to pair programming tasks during the interview process. Most of them are reasonable, but there are a small number of scenarios that most definitely aren't.

"Black & White" timed technical tests
Have you asked, or been asked, to conduct one of those online "technical competency" tests which feed a score back at the end to the hiring manager? The ones that explicitly state that they can detect moving away from the browser tab and if you do so (say, for example, to go and use Google) you immediately fail? Even worse is when you take that score, and you pass or fail the candidate based solely upon it. If you ask candidates to do this, stop.

Think about it for a second - when you write a piece of functionality for a product, can you confidently say you do so 100% of the time without using an external reference? If you answered yes I suspect you might be lying, or superhuman. Not a single person I know is able to recall every method, function or nuance with a language so why expect a candidate to?

These tests are not realistic and do nothing but highlight what a candidate has managed to imprint in their brain rather than what they know or how they approach a problem. If the candidate's score is ridiculously low then that's a different story, but programming is not about how much of a language we can recall.

I had a PHP technical test like this once - scored something like 64%. Been using PHP for 20 years, immediately got ejected from the process. In honesty it actually made me feel pretty dreadful and gave me a really bad case of imposter syndrome at that point. That is until someone I know ended up working for the company - and I realised I dodged half a dozen bullets.

Unpaid tests that form the basis of a piece of work on your backlog
I mean, if you have a way of doing this that is completely isolated from your main codebase so the candidate doesn't require previous knowledge then great. But it's still unethical. If you're going to use someone's work from a technical test, pay them.

2 day technical tests
I have been asked to do this on three separate occasions now - the first time I obliged. I got offered the job but I had my work scrutinised - the ironic thing was the quality of my work far surpassed the majority of the work I saw and experienced at the company. The second time I was asked to do one, I outright refused - I ended up on a remote technical interview with some pair programming instead. The third time - fairly recently, in fact - I was sent a job description for a rather well-known crowd funding investment company. While I wasn't looking for an opportunity, I had a look through it to see if there was scope for me to recommend someone - and I came across this:

"We have a multi stage interview process"

Rarely do I see companies highlight their interview process straight up, but stage 2 was a "2 day home technical challenge". Nothing implied it was a paid technical challenge so you have to assume it's unpaid.

I called it out - it's excessive and unnecessary. Different if it's paid, but at this point in time especially there is a shortage of good developers so why would any company think it's appropriate or even something a candidate would have time for? On top of this, they're using a technical stack that has a severe shortage of experienced resource in the industry as it is.

Unsurprisingly I never received a reply, nor have the company in question updated their job spec - I suspect their search is not going too well.

If you are doing any of these three things when trying to find a new addition to your team I would strongly urge you to stop. A technical test should be used as a method of understanding how a candidate approaches a problem, and a good way to open a dialog and get conversation flowing in a face to face interview.

A good length of time for a technical test is realistically a couple of hours. If you cannot assess their abilities from this then I suspect your approach needs review, or you're not entirely sure what you're looking for. Whatever the reasons, it is unfair to assume candidates have the time to dedicate. Consider that they might be working on four or five other positions and a two day technical test especially becomes untenable.