Interviews Can Be a Terrible Way to Identify Good Programmers

He makes a brings up an interesting point about the idea checking the effectiveness of interview methods. It seems that lots of people have intricate hacks for divining the talented programmers in an interview, but NO ONE can back their methods up with hard data based on performance and non-performance of candidates over project time-spans.

The author places a lot of stress on memory. I think he's overgeneralizing from his personal experience.

Personally, I have a very bad memory, especially when confronted with query-like questions like "explain how you solved some hard problem when working at company X". I remember based on associations, not time: If you sit me down in front of the code I wrote, or pose the problem to me directly, I'll remember in a jiffy, but looking back on my time at a company/at school/etc it just seems like a blur---I can't remember anything at all that way!

To fix coding interviews in this country, you need to insist on having a great coder do the interviewing. In 90% of the interviews I go on, I get evaluated by an HR type who could not write any program more significant than Hello World.

What's funny is that the Non programmer interviewers are starting to administer coding tests, and they don't know what a good response is! So here I am doing a coding tests on a white board, and and I'm being tested on delivering the optimized code on the spot, basically producing the best code. So now instead of birdseed knowledge tests, we are tested for creating an algorithm from memory on the spot, a memorization game. Like Jeopardy. That's not how the best coders code, we offload most things to google searches and general process of cutting code. They don't realize this because they evaluators can't write a program. They can only understand one specific algorithm and its implementation.

So the only way to get a good coder is to take your best coder, and then hand him a stack of resumes, and ask him which ones to bring in, and have him sit down with the recruits and have him give an up or down vote.

Using non coders to filter coder resumes? The time is better spent hiring a monkey to throw darts and hire the one with the most darts. I don't care how many books on coding interviews they read.

/sigh interview techniques really are a perennial topic on HN.

> [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.

[1]: http://www.linkedin.com/in/andrewwulf

Alternate Title: I have no social skills but I know C++, GIVE ME YOUR MONEY.

too whiny for my taste.