Interesting idea. But I wonder how much it helps to use a classifier for processing resumes. If you have a high number of resumes to process it makes sense to attempt to automate it. But if the volume you are processing is low enough you might be able to get by with letting people make decisions.<p>For example I can tell way better than Google's spam filtering software whether an email is spam or ham. The only reason to use filtering in that case is to save me the hassle of having to dismiss 50+ spam messages per day.<p>The human mind is pretty good at picking up patterns (even without trying) so after a while experienced interviewers start to see what kind of people worked out and what kind of people they hired and later regretted it. I guess using a naive classifier would eliminate some bias towards things like top colleges and years of experience.<p>The real problem with resumes however is that anyone can put absolutely anything on it. So it's a bad source for training a classifier. It would be interesting however to measure things like the probability of your interviewers making correct decisions, or (if you use standard questions) the correlation between answers to questions and performance (in the event of a hire).<p>Ultimately I think I agree with Joel that the only proper way to decide if someone is worth hiring is to have a technical discussion with them and see how it goes. Getting a feel for how someone writes code is even more important (but I'm not necessarily sure that putting people on the spot in from of a whiteboard is the best way). After someone has been hired I can usually tell withing several minutes of working with them on real production code whether they were a good addition to the company.