We have been doing a lot of technical interviewing lately trying to find new candidates for open positions. It has been challenging to say the least to find quality people. Even if we find quality people, they have often failed at a 2nd stage interview.
I came across this article in my daily reading today:
If you have to hire technical talent – take a few minutes to read the above, its worth the time. It speaks to the problems with technical interviewing today. It is spot on and addresses the problem of the interview itself. It is only a tiny window into the capabilities of the candidate. You need to talk to and interact with the candidate multiple times before you can really assess their skills.
In my interviews, I always want to make sure at least one other person interviews them separately. Ideally at least 3 separate interviews with different interviewers across at least 2 days. That way you can really get a sense for their skill and personality.
What about Coding Tests?
Experience shows me they are a waste of time. I’ve used them to hire. They did not predict whether a candidate could code at all.
I’ve done them for job interviews and failed them. Ha. Yeah, really. I’ve been coding for 36 years and have built every type of system under the sun. But, there have been cases where I’ve failed tests because the tests suck.
Yeah I said it coding tests SUCK.
Testing someone over an hour or two is meaningless. Testing their knowledge and usage of some obscure algorithm or some weird JavaScript library is not useful. If anything it can give you a false positive. Someone who can implement bubble sort really well is not necessarily even remotely a good developer.
Based on the stats I’ve seen most people are taking the tests are failing. So really, all you’re weeding out a ton of good candidates over some arbitrary test.
I don’t put a lot of stock in the automated coding tests that are becoming all the rage. Why?
- They are often so contrived to be not relatable to the real world. Who cares if someone can recite and recreate quick sort in Go?
- They can and are cheated, all the time. So if you get some one who aces the test – can you really trust the results?
- The results aren’t trusted when someone DOES score well. Example: I’ve interviewed three times with a company. (Long story, but I did work with them and was offered a job 2 of the 3 times.). This company use the CCAT test – a standardized timed online test with 50 questions. I scored 47, 45 and 50/50 in my tests. All of these are very high like 98th percentile or higher results. Yet the company said they only do the test because process – no one cares about the results because they think people cheat the test. Yikes.
- Automated tests almost always work with niche libraries within a technology, testing esoteric library knowledge and not coding knowledge.
- Finally, online coding tests that aren’t simple, contrived examples, often expect you to build a complex application solution in an hour – and then you get judged on whatever piece you completed. Hiring managers should be interested in code quality, not raw coding speed.
So what is better? White boarding, discussion, and explanation. Ask your candidate to talk and walk through something they built. Ask for details. Then ask for more details. If they built it, and they truly understand it they will be able to describe it in detail, including how it was built, why decisions were made, and what problems they solved. White boarding and discussion can be far more informative of a person’s history and knowledge.
Candidates that can do that – are the ones you want to hire.