Comment Giving tests worked great for me (Score 1) 440
I was test manager on a 50-person project. The development manager and I noticed that we had managed to hire a bunch of people who couldn't code their way out of a loop. I guess this showed that we weren't good interviewers. What we did about it was to write some tests of our own and give them to candidates. I never had a person decline to take a test. We did find that our tests discriminated quite well between candidates, and we found that we ended up happier with people who did well at our tests even if they couldn't talk the talk well.
All of our tests were very straightforward, no surprises or curve balls. And since we were the ones who had written the tests, we knew the material well. Some of the questions, we knew there were very specific answers to. Others, we just asked, "Here's a thing. Say something interesting about it." We calibrated the tests by giving them to current employes. We revised them until the people who were doing good work did well on them and the people who were doing poor work did poorly on them.
The better candidates pointed out errors in the tests. The best guy was someone who obviously thought a lot like me. After 10 minutes, we both got so involved in solving a coding problem that we forgot we were in an interview. He was a great asset to the project, at least until he decided he wanted to work nights so he could have another job during the day.
Bottom line: there's no way I'd hire a programmer or tester without seeing them program or test. Or in the ideal case, both.
(We made sure that the content of the tests was not related to the content of our project, thus avoiding even the appearance of asking for free work, unlike the slimeball referred to above.)
All of our tests were very straightforward, no surprises or curve balls. And since we were the ones who had written the tests, we knew the material well. Some of the questions, we knew there were very specific answers to. Others, we just asked, "Here's a thing. Say something interesting about it." We calibrated the tests by giving them to current employes. We revised them until the people who were doing good work did well on them and the people who were doing poor work did poorly on them.
The better candidates pointed out errors in the tests. The best guy was someone who obviously thought a lot like me. After 10 minutes, we both got so involved in solving a coding problem that we forgot we were in an interview. He was a great asset to the project, at least until he decided he wanted to work nights so he could have another job during the day.
Bottom line: there's no way I'd hire a programmer or tester without seeing them program or test. Or in the ideal case, both.
(We made sure that the content of the tests was not related to the content of our project, thus avoiding even the appearance of asking for free work, unlike the slimeball referred to above.)