Slashdot Mirror
Pre-Employment Skill Set and Aptitude Tests?
stumbler asks: "I just had a lengthy conversation with my boss and co-workers about the value of giving skill set tests (programming ability) and aptitude tests (like reasoning or logical ability) to technical employees before they are hired. (We currently have no such tests.) For those that work in companies that require pre-employment tests, have you seen an impact in the quality of technical employees hired?"
They hired me. Which means the skill set tests don't have value! Any standard test can be gamed.
If I remember, those who past generally were well liked by the others who interviewed them.
Then there's the grammar test....
-Tolerate my intolerance
Pre-employment tests are sometimes good for generic categorization of employees. Skills and aptitude tests are quite different from cognitive and behavioral tests. If you've ever taken either of the latter, they can be laughable. The problem is that hiring managers give those tests to a candidate, see "Inability to focus" and "Cannot develop strong relationships" on the results, and assume that's bad.
Give the same tests to your current employees and try to correlate the results. You'll undoubtably find a few patterns amongst your excellent employees that differ from your mediocre employees. The more results you collect from candidates that you know are horrible along with your employees, the better you'll be able to customize the feedback for your exact environment.
In a previous job, I found that all of our core software developers did fantastically on a general cognitive test (IQ-like), but that most did horribly on behavioral tests -- they were all "Likely to be insecure with their work". In fact, potential candidates that were also "Likely to be insecure" often matched the personality profile that worked in our group. So, test your own employees and see what happens if you highlight candidates that perform similarly to those employees that excel, rather than taking the simplistic approach of "a bad score must be bad!" with prospective employees.
You may find that if you give a variety of tests to 20 candidates, ranging from specific skillset assessment to leadership profiles, that you can at least take a harder look at the 3-5 candidates that score poorly across the board -- if they're barely above average (or worse) and they don't test well, that's not a great sign. Conversely, you could hire someone because they do a great job on all of the tests, but that would be equally horrible -- lots of people are good at taking tests and bad at producing actual work.
Assuming a handful of people with equal qualifications, why take the risk? Especially in this job market, there are too many people out there that not only have the right skills and behavior that can also do well on the corresponding tests.
Interview problem solving often has something in common with Adventure style games: Guessing what the author was thinking is more effective then solving the problem.
When was the last time you solved a real-world problem in a few minutes with someone looking over your shoulder who already knew the "correct" answer?
There is no reliable algorithm or heuristic for hiring the best people, but some companies are comforted by introducing pseudo-rigor into the process.
I am a hospital doctor, and we only hire doctors who have either come from hospitals we know (and can trust)
OR
we give them a short set of multi-choice questions, and see a few patients with them.
We find that the quantitative test (MCQ) separates out the complete no-hopers (like your test, but probably a bit more reliable as there are 50 questions), and that the qualitative test (watching them work) helps differentiate the good candidates.
Humorous signatures are over-rated.
That's a good idea actually. Put them in front of whatever IDE you use (whether they've used it before or not) with a program that has compilation errors, style errors, obvious bugs, a couple of subtler bugs and one very subtle bug.
:-P
Then tell them to make this code work, and see what they do. That will give you a pretty accurate idea of several things:
1) How quick-thinking they are - I know people who have "the skills" but apply them oh-so-slowly they're a frustration for their co-workers. Watching them code is like watching paint dry. Unsurprisingly they're also slow in other parts of day-to-day worklife interaction.
2) How they react to a frustrating problem - debugging someone else's code can be very frustrating. You can probably weed out the guys who get really annoyed and fretting... they'll probably end up pulling a heart attack on you during a stressful phase of the project! (note: that is actually discrimination based on health so you will get sued if you don't hire someone based on that. So don't do it, ok?)
3) How good they are at debugging. Having talented debuggers is useful on any project...
Sounds like a brilliant test to me... maybe because I would have passed it very nicely
Daniel
Carpe Diem
"Give them a wrong address for the company. Nothing too misleading , such as a different town, just be a few streets out."
It cuts both ways though. If I was applying to a company that hired people incapable of giving the correct address, I'd think twice. Likewise, if a company deliberately misled me as part of the interview process, it would be harder to believe anything else they said.
And the most you've done is prescreened people who can use Mapquest. Whoop-DEE-doo.
"For fun, give them some paperwork to fill out at the end of the interview and say "I just have to duck out and check on something - back in a tick". Leave and time how long it takes for them to wander out of the office in search of someone... 15 minutes to half an hour's a pretty good baseline."
Most of the interviews I've been to have had a specified time limit (or have been happy to tell me when asked). A lot of people don't have time to waste on interviews: they're either taking time away from their current job, or have the day off. Why waste their time "for fun"? Wasting 15-30 minutes of interview time is stupid when you could be doing something productive (like talking to them).