As an IT recruiter you can't be an expert in every technology out there. How do you ensure that IT candidates really understand the technology and have what it takes to do the job? Technical skills testing, right?Believe me, I wish it was that easy. Unfortunately technical testing for job screening is not as objective and accurate as it appears. Here are seven things to keep in mind when you use technical testing for job screening:
1) Test results don't reflect what it really takes to be successful on the job. Consider the intangible qualities that your most valuable technical employees bring. Are you looking for someone to help your team develop an innovative technical solution? Creativity, team-work, analysis and synthesis of existing solutions, out-of-the-box thinking, and dogged determination may be essential job requirements that won't be reflected in the test results.
2) Technical tests reinforce out-dated stereotypes. We all know the myth that technical people (techies, geeks, gurus) have brains that work like computers. Computers follow rules. Programmers, developers, analysts and architects figure out how to hack, collaborate, stretch and extend the rules to create new solutions. Programming is a literacy skill and an art. It takes both sides of the brain to do it well. The most in-demand technical gurus I meet are generous and driven creative problem solvers with extensive communities of peers in their field. I've yet to see a test that evaluates how a coder utilzes both sides of her brain to create new applications or extend a platform in new directions.
3) Badly worded questions. Some tests have ambiguous questions with multiple correct answers. But the anwser key only accepts one particular response. Sometimes the test taker knows more about the technology than the test writer/marker. The test taker might propose an alternative solution that the marker doesn't understand so it's marked wrong.
4) The test is out-dated. The test may not be up-to-date with the current state of the technology. Responses that were valid when the test was written a year ago may be incorrect now. A typical example of this is when a tester asks a job applicant to debug a piece of programming. A variety of solutions are possible but only one is known to the tester. So when the test taker proposes a solution that is up-to-date with current best practices his response is marked incorrect.
5) Irrelevant questions. Some tests ask people to define obsure technical terms. If you need to know the definition of a term while you're on the job, you'll just go to the knowledge base and look it up. When people develop technical solutions on the job they usually have free reign to reference any resource they need. People don't memorize manuals. Why bother when it changes every time the technology get updated?
6) The test taker might not take the test seriously. Imagine this: You're an in-demand developer who's spent years building a career in your field. You're at the tailend of a contract project you've been with for about 6 months. It's 9:40 am and you've just finished an interview for a job you don't really need. The interviewer asks you to take a technical test. Sure, no problem, but they're waiting for you back at your current project. So you flip the test off as quickly as possible and high-tail it out of there.
7) Test-taking anxiety. Before I ventured into IT staffing I was a teacher so I've seen the effects of test anxiety first hand. Many people freeze in test situations yet they are very capable of performing in normal working conditions. These people will seldom ask for accommodations but they may have excellent experience and qualifications for your role.
How do you determine when technical testing is appropriate? Consider these questions: Does this job require someone who can develop a new solution or push out the boundaries of an existing solution? Then you might want to put more emphasis on the candidate's reputation, references and experience (portfolio) when evaluating them for the job.
Does the test reflect the way people really work? Is the test up-to-date? Does the test allow for multiple solutions? Do you have a technical person who can back up the test results with a face-to-face technical interview?
I'd love to hear about your experiences with technical testing.
If you liked this article you might also be interested in reading:
Technical Interviews: A Survival Guide for Recruiters
Posted By Tim Collins, President and Founder,
Stafflink Solutions Ltd
No comments:
Post a Comment