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 done them for jobs 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. If I am failing – and based on the stats most people are taking the tests are failing – then 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 can and are cheated, all the time. So if you get some one who aces the test – can you really trust the results?
- 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?
- 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.