> [a coding test] won't tell you squat about how good they are in a year long project with 10 other people,
The author misses the point of a coding test. It's a negative rather than positive filter. Someone who does amazing on FizzBuzz is not by definition an amazing programmer. Someone who can't solve FizzBuzz however almost certainly is not a good programmer.
Simple coding tests are a very effective filter in terms of the time spent.
> So why spend an inordinate amount of time on relatively minor parts of a programmer's skill set?
I wouldn't call half an hour "an inordinate amount of time".
The author then opines about how "can just tell" if someone is a good programmer or not. I can sympathize because frankly so can I. I went through a period of taking 10 interviewees to lunch. I asked them nothing technical and basically just answered their questions. From the first 10 minutes I could tell:
- 1 would probably get an offer (he did);
- 8 would not (they didn't); and
- 1 I was unsure about (no offer).
Looking at the author's profile [1] I believe I can see the problem: it doesn't appear he's ever worked for a large engineering organization. This is fairly obvious from the content of this post because none of his solutions scale.
Let's say you have a large organization with 5 Andrews. Each of them says to hire this guy they just interviewed. What do you do if you're looking for less than 5 people? Are they going to work on the respective teams of those giving the recommendation? If not, how do you know they're a good fit? You need to consider company-wise culture and expectations. How do you calibrate between them? Do they have the necessary foundation to do not just the job they'll be starting on but to grow with the organization, adapt and perhaps work on other projects?
The other problem I have is the "war stories" aspect. This is a very definite bias. Take the way human memory works. Imagine you have a conversation with someone that's memorable in some way. At first you can remember word-for-word what happened. That quickly fades and you remember the gist of what was said. You may even think you remember exactly what was said and how it was said but usually you're wrong (try it by writing down what was exactly said and going back to it after months or having two or more people recount the same event). After awhile even that made fade and you may just be left with an emotion about the event.
Some things I can remember very well but more often than not, I've learnt my lesson and the exact circumstances or even the origin entirely are lost. This is largely because it's useless information.
But here's the biggest problem of all with the post:
> My favorite idea is still contract to hire everyone after your (hopefully reasonable) interview;
Okay, you've excluded anyone really good because they're not going to jump through that hoop. I don't consider myself a "rockstar" and even I won't jump through that.
Maybe the real problem is the OP doesn't even know what good programmers are because this is a recipe for mediocrity.
Lastly there's a story about team bonding (probably distorted if not made up outright at a guess). The author doesn't seem to realize that his hiring process is pretty much about hiring people like himself, which is fine, but that's not the definition of a good programmer.
I've seen teams work well who:
- all work closely together and socialize together;
- never socialize together;
- work remotely;
- work on different schedules;
- and so on.
Don't confuse programming ability with culture fit and work style. Those are three different things all important.
In a large organization you're going to have some aspect of a common culture but very different team cultures (and even site cultures). Part of hiring in a large organization is recognizing that you're not trying to hire "you" and then working out how you can best use someone not like you such that they flourish.
EDIT: oh and if he thinks Google, as one example, hasn't done extensive data analysis on interview techniques he's nuts.