Disagree completely.<p>There are simply too many things that you learn in the interview that are too difficult to learn any other way. Having someone code is NOT about seeing what kind of code they produce (well maybe a little); it&#x27;s about getting to know as much as you can about them in as little time as possible.<p>I want to put the candidate under some amount of stress to see how they respond. After all, responding to stress (deadlines, technical issues, people issues, etc.) is a very important part of a programmers job.<p>Just a few of the things I usually learn with a short coding test in an interview right away:<p>- Did he understand the problem?<p>- How did he approach the problem?<p>- Does he appear as if he has any idea what he’s doing?<p>- Can he explain what he has done?<p>- Can he defend what he has done?<p>- Does he understand the concepts of order, cleanness, iteration, branching, recursion, etc., etc., etc...<p>- Based on this small sample, do I think he can do the work we need done?<p>- Do I like him? Will he fit in and be a good team member?<p>Of course, I share all of this with the candidate. There&#x27;s no secret agenda. We just want to make a fair assessment of fit. This is good for everyone.<p>All a take-home project does is separate those who can build superior code from those who can build good code under ideal conditions. This is nice to know, but not a very important metric in the real world.<p>Ideal conditions rarely happen on real projects. Why simulate them in the screening process?