in reply to Interview with a Programmer

Having been on both sides of the table, a few comments:

If an applicant is familiar with a skill/language, they should be able to apply that skill/language to a simple example or provide some examples of problems they have recently solved. dws's node (see above) talks about implementing Minesweeper, and another example is the Game of Life (Conway) -- both probably involve two nested for loops somewhere, and a programmer should be able to figure that out. Get examples of their logic to solve the puzzle, along with boundary conditions (that's important) like "What happens when you get to the edge?" and some idea of how to store the game board (two arrays, maybe?).

One of the links about interviews that I read recently frowned on the "Solve this mental challenge" type questions because either you got the trick or you didn't -- it wasn't really a good measuring stick for smart, methodical, get it done right type programmers. Without the "Aha!" moment, the applicant's sunk.

So, if they claim to know SQL, ask about doing a join. If they ask if you want an inner or an outer join, they may be showing off, or they may really know their stuff. You could also ask about the efficiency of using different fields for indexes. Or what foreign indexes are (hint: nothing to do with some other country's stock market).

If they claim to know Perl, ask some regex questions, some array questions, some reference questions, and about what resources they use when they get stuck (they must get stuck sometimes). Do they have any of the excellent O'Reilly books? What on-line resources do they use? Do they have a favourite module? A favourite authour?

Finally, shoot them through a little test -- I used to give candidates a one hour test. It pretty clearly showed whether their skills matched the contents of their resume. One more quick story: part of my test was to code a bubble sort in C (yes, I know it's N*N and not always that efficient). One applicant wrote out the code for the QuickSort algorithim instead. Later, I typed his code in: it compiled and ran correctly the first time. However .. I had not asked for "any" sorting algorithim, I had asked specifically for a bubble sort. So I rejected that candidate, because in my opinion he would go off and do his own thing after being told what to do, and that's not the kind of person I wanted to hire.

On a personal note..
Having just applied for a full-time job here in Toronto (recent post on PerlJobs) I am dreading the interview thing (if I make it that far), not because I don't know my stuff, but because I tend too often to give the two minute answer when all that's really required is the ten second answer -- I can't help it, that's just my personality -- I don't want to leave anything out. The result is often a glazed look on the interviewer's eyes that seems to say "Thank you. Next please."

--t. alex

"Excellent. Release the hounds." -- Monty Burns.

Replies are listed 'Best First'.
Re: Re: Interview with a Programmer
by toadi (Chaplain) on Jan 04, 2002 at 14:11 UTC
    START QUOTE
    code a bubble sort in C (yes, I know it's N*N and not always that efficient). One applicant wrote out the code for the QuickSort algorithim instead. Later, I typed his code in: it compiled and ran correctly the first time. However .. I had not asked for "any" sorting algorithim, I had asked specifically for a bubble sort. So I rejected that candidate, because in my opinion he would go off and do his own thing after being told what to do, and that's not the kind of person I wanted to hire.
    END QUOTE

    So I would ask how big the list was to sort and try to work out which sort is the best for that. So you wouldn't hire me because I'm not a brainless idiot who just does what you want???

    --
    My opinions may have changed,
    but not the fact that I am right

[reply]
(ichimunki) Re x 2: Interview with a Programmer
by ichimunki (Priest) on Jan 04, 2002 at 22:46 UTC
    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.
[reply]
      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]
        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]

In Section Meditations