Glennlist

Congratulations! You sourced one heckava nerdy IT software developer. You had a great phone interview where you both made fun of the iPhone crowd, and totally agree Iron Man 2 was a let down. Now what? You gotta get this Pizza-eating-Mountain-Dew-drinking-Supernerdyfragilisticexpialidocious developer a technical interview. And, you’re dreading it because he is going to fail unless he has Bill Gates super geek coding powers.

But before you make that dreaded call to your Hiring Manager who is going to hand the technical interview over to a guy that sits in corner cube displaying dungeons and dragons fantasy figurines, you might want to ask them if they really need a technical test.

Seriously, tests suck. But, we’ve all had to take them. The problem with these technical tests is that either way too broad (as in pulled in from a Google search) or they reflect the current role which is pretty much a hybrid type role. What do I mean by hybrid role? It’s when you combine several skills into one super duper geeky job. And this has been a trend since the economy tanked.

What I am really getting at here is quite simple. Tests aren’t that good sometimes because they are made for the current position. And in some cases, those giving the test failed it too.

So unless the technical test is customized for each candidate, I think you are throwing out the baby with bath water when the candidate fails. And for all the sourcers that I know, this strikes a nerve especially the amount of effort it took to source the candidate. And once candidates begin to fail technical test regularly, sourcers often find themselves screening candidates with the technical test.

The big question still remains. Do we really need to give a technical test? And, if you do need to give tests, where in the process? I can tell you right now, technical test that are used to screen out candidates is a flawed concept.