Interview Selection Principle
Update (2020-08-07): This is a republish of my sixth blog post, dated 2010-06-21: Interview Selection Principle. Devblog won't let me backdate this before 2015.
I gotta say, I think this is my favorite of the seven posts I made years ago. I think it's held up fairly well. (I cringed reading most of the other ones.) The backstory is that I was interviewing for a new job at several different companies back then. I had to practice whiteboard-coding and memorize some Big-O values from Wikipedia to get in the door for all of them.
And, no, I have not yet written more than a few lines of code on a whiteboard since I've been working at Google. :)
(Since I'm least embarrassed about this post, maybe I'll try letting Devblog "Show this on Hashnode". It may be the last one I do this with as well, but I suppose it can't hurt to let this one fly.)
You get what you interview for. That is, the selection criteria used during a company's interview process dictates the type of candidate that company will likely hire. For lack of a better name, I've dubbed this the Interview Selection Principle.
I bring this up because it seems to me that a lot of high-tech, and well-respected, companies aren't getting their interview process right. I wrote about one example of this in my previous post, with respect to coding on whiteboards .
If you ask your candidate to write code on a whiteboard, he passes with flying colors, and then gets hired, all you've done is made sure you that your new employee can write good code on a whiteboard. But what skills does that process select on?
One skill shown by that would be the ability to hammer out a logically-correct design in one shot. That may be a nice skill for a programmer to have, but is it necessary? And, more important, does it necessarily make for a Great Programmer? It's a fair argument to make, to say that having this skill can be a predictor, but that's no guarantee.
I, for one, do not always hammer out a good design the first time I write code. But, I'm willing to bet that I can complete a project with fewer bugs, an easier path forward for new features, less required maintenance, and in less time than most programmers. You see, being able to "Get It Right" the first time was great when programmers had to put holes in punch cards, but that doesn't much matter now that you can cut & paste a section of code, search & replace the name of a variable, and delete large swaths of code -- all with a few keystrokes in Emacs or VI.
Another criteria many tech companies seem to focus on is knowing the Big-O notation for various algorithms. If someone can pass your test by knowing the correct answer is "O(n * log n)", all you've done is found someone that can rattle off something that most programmers would just look up in Wikipedia. Can knowing these arbitrary things be a predictor for Great Programmers? Possibly. I mean, if a candidate knows that stuff, it probably means they at least have a basic understanding of programming (whoop dee doo).
But, I admit, I don't know the exact expected times for most algorithms off the top of my head. And -- you know what -- that doesn't matter. Why, you ask? Are you thinking that I'm going to, someday, waste my time implementing some algorithm only to find that it's untenable because it's "O(n^2)"? Well, I have three responses to that...
First, the situations where a programmer has to design and write new code for some large dataset, where speed matters, are few and far between. It's not what most programmers do every day.
Second, and more important, if a programmer is a Great Programmer, he/she can rip out that slow algorithm and write a new one in less than a day. Remember, we're not working with punch cards here. They can delete the crappy nested loops with a few Control-K's in Emacs, and then call off to some nifty hash implementation. And, because a hash should be simple to a Great Programmer, they can then write the hash implementation in less than an hour. After that, they'll still have time to improve their hash function and have leftover time to grab a snack from the company kitchen.
Third, I believe one thing that makes for a Great Programmer is instincts. There's an instinct in Great Programmers that makes them check if a pointer is NULL before dereferencing it, if (and only if) there's a chance of it being NULL. There's also an instinct that makes sure to always free() allocated memory in the appropriate place. And, another instinct is to not unnecessarily loop through large sets of data.
So what should a company do instead in their interviews? Well, you'll already know one thing they should do if you've read my previous post: ditch the whiteboards already (for interviewing)! But, more to the point, have each candidate write code, on a computer, that does something. And, yes, that something can be to sort or search some data.
In other words, don't just pick out some data points (like knowing the Big-O for merge sort) and try to extrapolate whether or not someone's a Great Programmer. Instead, just directly put them to the test to see if they write code like a Great Programmer! Do they implement an exponential algorithm, and not even realize it? Do they use recursion for each element of a list that might hold billions of elements, not realizing they can blow their stack? Now that they have the power of cut & paste, are they repeating code that should really have been pulled out into a function?
To get back to the Interview Selection Principle, assuming you hire what you select upon during your interview process, why not select upon actual, real-world programming?