On hiring programmers - writing code before the interview

What prompted this post was this job ad for an experienced web developer by Netpositive and the discussions that it prompted - and the realization that there is no way I can explain my view within twitter's limitations.

I liked the ad because as a prerequisite for being invited to an interview, applicants are required to write a little web application (regularly read from an RSS feed, store it locally, display the posts on a page (with paging), and add Facebook's "like" functionality to the page).

Being able to conduct an interview based on code the candidate written at her own time before the interview has the following benefits:

• the interview-fever problem is eliminated - some smart people can't solve simple problems during the interview they would be able to do in a minute under normal conditions
  
• those that can talk the talk but can't apply the theoretical knowledge to real problems don't get past this filter
• those that cannot sell themselves during the interview but are good programmers can be considered
  
• as an interviewer, I can focus on what the candidate knows, can ask them to suggest ways to implement new features in an application they already familiar with
  
• it is more fair for people who might not know the jargon and terminology (though they certainly should learn it later), but are good at programming
• you can learn a lot that might not be uncovered in a regular interview, e.g.: how likely the candidate is to reinvent the wheel rather than looking for existing solutions
• the interviewer can screen applicants for requirement analysis if needed - just give an ambiguous enough spec
  
• those candidates, who just want to get a job rather than a job at the given company are likely not going to apply because of the extra effort required here. Some great candidates will not apply either; however, I think that is an OK risk to take.
  

The hardest thing with this approach is picking the problem to be solved -

• should be big enough, not just a one off script, but something where some design is required, so the interviewers can learn about the candidate
  
• should be small enough so a good candidate can complete it in only a few hours;
• should be a problem relevant to the job the opening is for, not another hello world program;
• should be such that it's not a problem if it's googleable - we all google all the time, the important part that the candidate should demonstrate an understanding of the googled solution
  
• should obviously not be real work for the company - I would not want to apply to a company that wants to use my work for free to deliver to their customers.
  

I'm not even going to attempt to give a silver bullet solution that satisfies all the above, because - as everything in the software field - it depends on your context. However, the below ideas could be used as starting points:

• problems from online programming competition archives, e.g.: UVa Online Judge, Sphere Online Judge, etc.
• dedicated online screening applications, like Codility
• using tasks (bugfix, new features, etc.) from OSS projects. Yes, it is free work in a sense, but it contributes to the applicant's resume and makes the world a better place! :)