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?"

Comments

Re:Some I gave during interviews

[mrgrey]

If I remember, those who past generally were well liked by the others who interviewed them.

Then there's the grammar test....

Create a reference point

[Plasmic]

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.

Re:at my work

[Sad Loser]

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.

Re:best one for a programmer

[KDan]

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.

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 :-P

Daniel