There’s been a lot of buzz around the blogosphere lately about various issues with interviewing programmers.
One of these days I’d like to do a study. I’d find a very brave employer who needs to hire 100 people. We would use traditional interview techniques to fill 50 positions. For the other half, we’d pluck reasonable resumes from a pile, choose 50 at random, and just hire them.
After a year, I would return and talk to management. My guess is there would be no significant difference in the performance of the two groups.
If you are anything like me, you’ve been on both sides of the “hiring table” enough times to know that my hypothesis is probably right. There are just too many ways that an interview can fail.
If you don’t ask any tech questions at all, you can end up hiring someone who literally cannot code. Most employers are terrified of these “false positives” and so, instead, they make their interviews highly technical. They only hire people who can remember, on the day of the interview, how to solve the dining philosophers problem, or how heapsort works. However, nerd brains have aggressive garbage collectors which quickly expunge unused information. In English: they forget stuff. This leads to a high “false negative” rate — which is a more insidious problem because it tends to inhibit diversity.
A team with 5 heapsort experts is likely to suck for the same reason that a rock band with 5 drummers would suck. But I digress.
The typical whiteboard question is highly ego-centric. We go into a little room with a question that we’ve asked a dozen times and understand fully. We pose this question to a “lesser” nerd, in a high pressure environment, and carefully note all the missed semicolons. We chuckle to ourselves, secure in our supreme geekhood.
Ego deflation alert: 100% of these candidates could turn around and immediately ask an “interview question” that we could not answer. Oops. Who’s the idiot now?
By focusing on the whiteboard, interviews typically fail to evaluate candidates on many orthogonal — but critically important — axes. For example, how well does the candidate learn? How well do they teach? Do they ask good questions? Are they able to speak and write clearly?
Almost regardless of what questions you ask, there are a number of things that your interview cannot possibly measure. These are things which require months, not hours, to ascertain: work ethic, initiative, team skills, personality, team compatibility, self-motivation, ability to compromise, creativity, etc.
I think the only way to fix this system is to restructure the entire employment process. The root cause is that it’s currently way too hard to fire someone. If professional programmers were more like professional athletes — hired on a contract basis for a specific duration — things would be much different.
Latest Comments
RSS