I am a Good Software Developer

An anonymous article doing the rounds explains that the author is a bad software developer:

I am now in the buffer zone and have interviewed with close to ten companies to date. I have not been offered a single job and have not made it past the technical interview in most cases. I am a programmer. Until recently I had believed I was a good programmer. However in an industry where hiring practices have adjusted to filter out the plethora of bad, unqualified candidates I’ve found it rather difficult to consider myself a good programmer any longer.

If we are to take the proportion of job interviews that lead to an offer as an indicator of how good you are as a software developer, then I have to face the fact that I am a good software developer. Not just good in fact, pretty close to as good as it’s possible to be. My current hit rate is very close to 100%.

Of course, this is ridiculous. But I thought it might be instructive to put some thought into exactly why this is wrong.

Firstly, job interview success is localised: what constitutes a reasonable level of success will depend on where in the world you are, what industry you work in and when you are applying. From what I’ve seen, these facts dominate the effect of how good you are at your job.

But let’s suppose you’re comparing yourself to your friend who works in the same industry, at the same place and time. It’s still not useful to compare yourself with them because of the amount of random variance involved. If you’ve been rejected from ten companies then you might have been interviewed for less than 20 hours in total. That’s the equivalent of less than three days’ work. Most people wouldn’t conclude after three bad days at work, even a bad week, that there was something fundamentally wrong.

Thirdly, interviewing well is a skill in itself. Those of us who have conducted interviews like to convince ourselves that we did all we could to differentiate people based on how well they could do the job, ignoring things like interview nerves. We even rationalise the fact that the people who communicate the best have the best chances at interview, on the grounds that communication is an important part of working in a team. This is true of course, but communicating in familiar situations with people you know well is very different from communicating with someone you’ve met ten minutes ago.

As well as communicating and thinking on your feet, interviews disproportionately reward people who are immediately likeable. It’s not fair, and I’m sure people would deny they do it, but when you take a liking to someone you overlook their flaws, and exaggerate their qualities. Again, the superficial likeability that works well here is a completely different thing from the personal qualities that make someone a loyal friend or a supportive colleague.

Finally, there’s a strong tendency in interviews for success to breed further success. When you go into an interview with an offer already in the bag from your last interview, you’re more relaxed and confident. Conversely, the awful feeling that you have something to prove or that you won’t impress the interviewer unless you perform at your very best is self-defeating.

I’m sure the original poster won’t read this, but I’ll try and provide my two cents anyway: looking at the number of successful interviews is a really bad way to measure yourself. Technical interviews at different companies have a lot in common, so going to ten interviews is likely to tell you the same thing ten times. If what it tells you is that you meet their standards, this can be very reassuring, but it’s equally false either way. Instead, try to get qualitative data about what went right and wrong in each case rather than playing the numbers. If the company gives detailed feedback (and I believe they should, though not everybody agrees) then you should take as much information from each interview as you can. If you can’t get feedback from the interviewer, talk through what you remember of the interview with a friend. Try to be as objective as possible. Question your assumptions.

If you’re being rejected at the first round, and if you didn’t make any obvious technical blunders, then consider whether you may be trying to over-complicate things. First round interviews in particular tend to have closed solutions that aren’t very complicated, and the bar to clear isn’t always very high. Don’t stumble through implementing a complex data structure without first asking your interviewer whether a naive approach is acceptable (showing that you recognise the trade-off of program efficiency against development time). Even if you’re stuck, talk through your thinking and show a willingness to learn from any hints you are given. Showing that you can learn from the interviewer (and displaying a positive attitude as you do it) is a remarkably strong trait to show. Most importantly, do not ever give up on a problem until the interviewer asks you to move on.

I wish I had a better conclusion to draw. Interviews suck. Some companies do a better job than others, but nobody is perfect here. But I believe anyone can learn to make themselves a better interviewee, even if in an ideal world it wouldn’t be necessary.