When looking for new hires, many companies make the mistake of requiring all candidates to complete a simple skill test. At first, these tests seem like a good idea, and a quick way to eliminate a huge chunk of possible applicants who aren't as technically proficient as you need them to be. However, often times, these "simple" tests offer no real benefit to the employer, waste time for both the employer (and it's developers who have to sift through the results) and the applicant, and can actually have detrimental results on your hiring campaign.
Reason #1: Insulting the Wrong Crowd
Let's suppose that you're looking to hire a few mid to senior level developers for an object-oriented PHP position. So, you may spend the course of a week developing some really great, practical PHP questions and problems. After you've posted the job on dice, you've got a few offers, yay! Kindly, you'll send them an email with your "simple" questionnaire attached and give them a 24-hour deadline to complete the problems. Well, right off the bat, you've turned off a number of qualified candidates by requiring them to take time out of their day to submit a blind PHP test that is admittedly "simple". Many of the most qualified and highly sought-after candidates may view your test as beneath them, too basic, boring, and a waste of time. Some of the most qualified candidates may have years and years of experience (some may have even more than you!); they may have built some extremely successful and robust projects far beyond the range of what you are even hiring them for; they may have advanced degrees, have started their own companies, done consultant work for even larger companies; they may also be recognized leaders in the industry... Those are precisely the kind of applicants your company needs, but also precisely the kind of applicants that feel an aptitude test (with basic aptitude questions) is well beneath their skill level. "Any position that may require completing such a simple test, is probably a low-level code-monkey style position anyway."
Reason #2: Logistics
Let's take a second to think about the types of people are most likely to excel at a "take home" aptitude test. Chances are you've run into these same people before... These people are great test takers, and they excel at scouring the web and regurgitating information verbatim. They will put in long hours, and they can afford to work all night on this test, mostly because they don't have as many other applications to fill out as the more qualified candidates. They spend hours finding the exact right answers (which they did NOT already know and probably didn't even take the time to comprehend). They'll polish up their answers, add some extra bells and whistles to their code (such as CSS styles and simple Javascript), and submit their results to you just before the deadline. On the surface their results look great, but they are not there to explain their answers, describe to you their thought process, or even tell you how they arrived at their conclusion. So, all you're really left with is some simple, regurgitated information from the web looked up by the same person who's cheated his or her way through the majority of his or her academic and professional life... probably not your ideal candidate.
Reason #3: Missing the Point
In the tech industry, code tools, languages, and platforms are often times stressed as the most important aspects of an applicant's resume. This couldn't be a bigger misconception. The truth is, an applicant's ability to think, design, problem-solve, and engineer overall solutions will determine his or her success in any technology-laden position, not his or her experience with a particular language. Everyone knows a guy who has 20+ years experience with C programming, but has no concept of how to design a scalable, robust, object-oriented application. His experience far out-matches that of a newly graduated Doctoral student, but when placed with the responsibility of designing a system from scratch, he has no idea which route would be best to take in order to solve the problem, he just immediately starts hacking his C libraries. With an aptitude test, you may very well validate the applicants who've memorized all the built in functionality of their particular language, but you really haven't evaluated their ability to problem solve efficiently, which, is really what development is all about.