in reply to
Re: Interview with a Programmer
in thread Interview with a Programmer
Wow. I think rejecting the candidate over the sort algorithm implemented was probably not the best idea. Maybe he is confused about which sort is which, or doesn't know bubble sort but does know quicksort. Me, I don't even know either sort, and wouldn't bother to remember the bubble sort if it is known to be generally less useful (as your own statement indicates). Finally, the test you gave only tests a specific piece of knowledge and you discarded the most important information you got from it. This coder wrote working code the first time through-- code that probably satisfied the real requirements of "sort this list efficiently".
Personally, I think a better one hour test would be something like spending an hour solving some random problem-- something like scoring a bowling game or a golf game (as in +/- par) or giving the candidate a calculation for something fun like compound interest and making them implement an interface for several views of it. But in addition to the code itself, watch how they solve it, do they ask good questions about requirements, how do they validate their code, are they fluent or do they rely on compiler warnings to get code correct, etc. Of course, I say all this as a mostly impartial observer-- not as a hiring manager in a programming shop, nor as a programmer looking to get hired.