So xkcd had a delightful comic a few days ago about Ineffective Sorts (and below), and it really struck a chord with me. I’ve often hear of people being asked to (pseudo)code quicksort, or something similar, during an interview. This really irks me. If on the job a boss says, “Quickly Josh, we need a quicksort!!”, the last thing I’m gonna do is sit down and stare at a page of pseudo-code riddled with off-by-one errors. Nor am I very likely to go back to the textbooks and look it up (a much safer option anyway). Am I really being hired to reimplement STL or Boost libraries? Because those guys look like they got this stuff pretty darn well. And its super tested.
But you, my avid reader, protest “it’s a test to see how you think and reason”. Okay that’s fair, but I, for the sake of discussion, claim quicksort and other standard algorithms aren’t the right way to test an applicant’s reasoning ability. All applicants know quicksort could be asked, so we all look it up. Now, when we are sitting down during an interview, we’re trying to recall all the intricacies of a mature algorithm. Instead of reasoning through divide-and-conquer, I’m thinking “oh crap, now how to I pick the pivot to avoid those QS-attacks?”. I’m trying to remember how to get all the details right, when I should be iteratively addressing problems as they arrive.
Of course, if you’re hiring someone to squeeze out the next 1% of execution time in some DB-query, then absolutely he or she should know every damn intricacy of the standard algorithms. But for the rest of us, I think non-standard brain teasers or puzzles seem much better than reproducing a well-known mature algorithm.
IMHO =)
At my company, in order to try and keep our inteviewing process relevant and effective, we are trying to pull in more interactive interviewing techniques. Less of the ‘quick solve this problem!’ questions and more interviews that actually get to the meat of what programmers do day in and day out. We’re going to start experimenting with pair-programming interviews, where the interviewer and interviewee solve real (or ‘real’, or real-ish or Real^TM) problems together. This should hopefully determine the things we actually care about in our co-workers: how easy are they to work with, do they think on their feet, do they understand the code they or their pair writes, and how easily can they solve problems with a computer with The Googles installed on it.
Hey Davy,
Thanks for sharing! You make it sound like you’re getting new ideas externally, is there some secret conference ever year where tech hirers exchange ideas or best practices? I’m guessing not, but I think it’d be a very neat conversation to listen in on =).
I love the idea of real-er problems; I love the idea of attempting problems that need more 20 minutes. Sure you can’t do it all in an hour interview, but I’d be embarrassed if I could show someone the sum total of my ability in an hour, anyway…
“Take chances, make mistakes, get messy!” — Mrs. Frizzle