.NET Answers

It has always struck me as an odd practice to give a written test to an interviewee during the hiring process.  I’ve been on both sides of the hiring process.  I’ve had to take a few of these tests.  My general perception is that all a test shows is that the person taking it knows how to take a test.

I’m going to approach this topic from the hiring manager’s perspective since that is the only perspective that really matters.  I could go on about how it is unfair to me as a potential employee, but that wouldn’t convince those who need to be convinced.  So here are some points to consider when considering testing as part of the process:

• Have you adequately tested the test?
  One would assume that the reason you are conducting the test in the first place is that you are under the assumption that this is the fastest, most reliable way to screen a candidate.  How do you know that is true?
• Is the test clear?
  One huge potential problem is that the test you are giving may not actually be clear.  I’ve taken several tests, especially multiple choice tests, where several answers appear to be right–where one could make a solid argument that they are all right–but only one can be selected.  It becomes a case of “what was this person thinking when he wrote the test?”  The test taker is at a huge disadvantage if he’s never met the person who wrote the test.
• Is the test fair?
  Related to the test being clear and adequately testing the test is the concern that the test may not even be fair.  The test may only test what the person writing it knows.  Do you really want another person in your organization that knows the same thing everyone else knows?  Obviously, they will all know a different amount of other stuff, but the core knowledge may be too restrictive and may actually harm your organization.
• What is the purpose of the test?  Could it be done more efficiently some other way?
  If you are really looking for a person who can take a test, or you are looking for someone who can define a set of terms, maybe a test is the best way of determining that information.  If, on the other hand, you are looking for someone who can solve problems, how is a test going to prove to you that the applicant can do that?
• What kind of employee are you really looking for?
  Are you looking for employees who can all answer the same set of questions the same way, or are you looking for employees who will be able to help each other grow?  Is your test going to help you get the employees you are looking for?

Maybe I’m missing something.  But I can normally tell a good programmer from one I’d never hire in about 10 minutes of technical conversation.  During that conversation I can ask the same questions I would ask on any test I might create but the person I’m interviewing can ask for clarification if it’s needed.

If he doesn’t, that also tells me something about the person I’m interviewing.

There was one time I was asked for a code sample.  Now, there’s a good test.  If you can’t get a good clean sample of code from an applicant, something that is easy to read, that gives you some idea what he was trying to do, then you’ll never get good clean code once you’ve hired him.

I’ve also been asked to solve small problems.  That’s something else I see as valuable.  That shows me how the person thinks.

Given the choice between someone who can define polymorphism, for example, but can’t use it, and someone who can actually implement it correctly, but can’t define it, I’ll take the guy who can implement it correctly.  If he can do both, all the better.

In my mind, tests are generally a lazy way to interview a prospect and tell you nothing valuable in the process.  Maybe there is a test out there that is useful, but I haven’t seen one yet.

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Related Post

• Find and report unhandled exceptions
• IE6 or IE7 Virtual PC Images
• Test Your Web Site Using Multiple Web Browsers

Bookmark to:

Hide Sites