STARR INSIGHTS: Two-step guide for technically testing developers
by Ian Bailey
I’m still beating the technical test drum, harder and louder than ever.
I’m convinced that clients aren’t getting the best candidates for their jobs because of the technical tests that stand between reviewing a CV and the first conversation. I’m firmly of the belief that there are much better ways of testing candidates’ technical ability and more importantly, suitability to the role, than a technical test done at home. However, for the moment, the technical test isn’t going anywhere. For those that insist / have to send them out to candidates, I’m going to highlight two points that I urge all hiring managers to consider:
1) The timing of the test. If the instant reaction to seeing a CV is ‘send them the test’, you’re relying on the recruiter to have done as good a job as you would have of selling the role and opportunity to the candidate. If a candidate has multiple opportunities ongoing, as all the good ones do, they’re likely to be in a situation where they have multiple interviews and technical tests to fit in to their days. If you have just sent out a test without speaking to them or showing any tangible interest in them, why would they prioritise your test over anything else they have going on? For the sake of a 30 minute phone call, you could have a world class candidate literally chomping at the bit to get your test done first.
2) Is the test actually relevant to the role you’re hiring for? Too many times, tests are used because “that’s what we’ve always used” or “everyone here has done this test”. So what?! If you’re hiring for a developer to build a hugely complex new clearing system, why are they doing a test that asks them to build a front office trading algorithm that needs a sub-second execution time? This relevancy question is all the more astounding as more often-than-not, the hiring managers have been developers themselves and quite often still are, so they know the broad nature of skills that are required to be a world class developer – to give a candidate something that’s going to test such a narrow slither of their skillset seems bizarre to me. “I did it when I joined in 2001, so why shouldn’t they..?”
I know that quite often these technical tests are driven from HR / senior management as a non-techy’s way of judging technical ability, so a simple scoring system is a great way of gauging how good someone is. Well, it isn’t. I firmly believe that they’re inhibiting managers from hiring the candidates that will come in and solve their problems quicker and more efficiently, save you all time and earn your bonuses.
I’d love to talk to anyone who has an opinion on technical testing, and especially if you disagree with what I’m saying here or in any previous articles on testing. Give me a call any time on: 020 3587 7007comments powered by Disqus