4 ms·
Your method has one huge drawback - time consumption on candidate's side. Before doing this test I would recommend a simple preliminary test to quickly eliminat
by vilda 12y ago
Your method has one huge drawback - time consumption on candidate's side. Before doing this test I would recommend a simple preliminary test to quickly eliminate obvious misfits. It's also in align with Joel's recommendation[1].
At the end, there's too much factors you can't uncover before hiring, that at some point more testing in meaningless. My experience is that everybody has a preferred way how to work and a preferred topics, and allowing them to do just then yields most benefits.
[1] http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html http://www.joelonsoftware.com/articles/GuerrillaInterviewing...
- kasey_junk 12y agoI absolutely think that your work sample project should have reasonable time requirements. I shoot for "a candidate that we would want to hire should be able to do this in 2-5 hours over the course of a week or 2". If a candidate is unwilling to invest that much time in our process, that is perfectly within their rights and I respect that. But I'm not going to sacrifice my time for them either. If I need to cut time commitments from my hiring pipeline I will do it at the interview component. I would gladly trade 4 hours of work sample time for a half day of onsite interviews for instance. As far as eliminating obvious misfits, I'd argue that a mechanical suite of tests (I like to provide say 70% of them to the candidate) gets much lower false negatives and much higher true positives than any "simpler" test you can devise. The Guerrilla guide is a very good starting point btw, but I think it misses the central problem, which is, interviewing is not a reliable way to filter candidates for software development jobs, no matter how you do it.