(ichimunki) Re x 2: 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.

Comment on (ichimunki) Re x 2: Interview with a Programmer

Replies are listed 'Best First'.
Re: (ichimunki) Re x 2: Interview with a Programmer by talexb (Chancellor) on Jan 04, 2002 at 23:13 UTC
I think we'll have to agree to disagree on this one. I did write up a pretty succinct description of the algorithim required for the test -- so it was really an assignment to implement a given algorithim in C. This was clearly not a real-world situation (that is, I didn't engage the applicant in a discussion of sorting algorithims), but then few tests are. To relate it a little more closely to the work I was doing at the time -- imagine if a legacy system requires that you do A, B, C, D then E, but the programmer you assign to do that task ignores that information and spends a week coming up with a much better solution that does B, E, D, C then A. It's coded beautifully, it's lightning fast .. but it's wrong because it's not what you asked for. What then? Finally, I am flexible. I remember one situation where I went to my best programmer to plan an approach to a particular problem -- I had one idea, and he had another idea. The result? Aha! A melding of the two ideas which was miles better than either of the original ideas. We were both happy with the decision, and the company got a great solution. --t. alex "Excellent. Release the hounds." -- Monty Burns.	[reply]
(ichimunki) Re x 4: Interview with a Programmer by ichimunki (Priest) on Jan 04, 2002 at 23:45 UTC
Well, now that you explain it differently we don't have to agree to disagree. We do in fact agree. :) If you gave the coder the logic/algorithm behind the code and they coded something else entirely that's a different scenario than you telling simply saying "write a bubble sort". Your example changes from a knowledge quiz to a follow the directions quiz. I would still hope the test was interactive enough to allow for the coder to point out that the interface to the sort could remain the same, but an alternate algorithm would probably be more efficient. And of course, you are then allowed to say "Well, the CTO outlawed quicksort because he doesn't understand it" in order to simulate the very real likelihood that eventually the coder will come across a requirements limitation that is totally arbitrary and maybe even counter-productive. And in such a test, a coder who handed in the wrong sort algorithm would certainly fail.	[reply]