I agree with the OP and not with you. What you are doing is arbitrarily selecting a subset of qualified employees. It _looks_ like it works for you, but its p

I agree with the OP and not with you. What you are doing is arbitrarily selecting a subset of qualified employees. It _looks_ like it works for you, but its probably not efficient, and can probably go wrong. When a developer is screened with tests like that, you are not evaluating them on their product, but rather on some set of skills that might overlap. I cant believe I'm using a sports analogy, since I hate team sports, but think of it this way. What if a football or basketball recruiter went to colleges, and looked at only how fast somebody ran, and how high they jumped, but never looked and how they played the game! Don't laugh, that's exactly what you are doing. You may have some success because you are screening out some dopes, but that's all you are doing. If I was the MVP on a team and some jerk took me aside and asked how high I could jump I'd be insulted. As the OP suggested, looking at the candidates past code is more like looking at how they play the game. If you suspect plagiarism, then have them explain it, beat them over the head with every design decision they made, have them rewrite something with your suggestions, it will become obvious if they wrote it or not, and you'll have a better idea if they know how to actually code, where it counts, at the construction level.