programming and human factors

22 Feb 2010

The Non-Programming Programmer

I find it difficult to believe, but the reports keep pouring in via Twitter and email: many candidates who show up for programming job interviews can't program. At all. Consider this recent email from Mike Lin:

The article Why Can't Programmers... Program? changed the way I did interviews. I used to lead off by building rapport. That proved to be too time-consuming when, as you mentioned, the vast majority of candidates were simply non-technical. So I started leading off with technical questions. First progressing from easy to hard questions. Then I noticed I identified the rejects faster if I went the other way – hard questions first – so long as the hard questions were still in the "if you don't know this then you can't work here" category. Most of my interviews still took about twenty minutes, because tough questions take some time to answer and evaluate. But it was a big improvement over the rapport-building method; and it could be done over the phone.

After reading your article, I started doing code interviews over the phone, using web meetings. My interview times were down to about 15 minutes each to identify people who just can't code— the vast majority.

I wrote that article in 2007, and I am stunned, but not entirely surprised, to hear that three years later "the vast majority" of so-called programmers who apply for a programming job interview are unable to write the smallest of programs. To be clear, hard is a relative term -- we're not talking about complicated, Google-style graduate computer science interview problems. This is extremely simple stuff we're asking candidates to do. And they can't. It's the equivalent of attempting to hire a truck driver and finding out that 90 percent of the job applicants can't find the gas pedal or the gear shift.

I agree, it's insane. But it happens every day, and is (apparently) an epidemic hiring problem in our industry.

You have to get to the simple technical interview questions immediately to screen out the legions of non-programming programmers. Screening over the telephone is a wise choice, as I've noted before. But screening over the internet is even better, and arguably more natural for code.

I still wasn't super-happy with having to start up the web meeting and making these guys share their desktops with me. I searched for other suitable tools for doing short "pen-and-paper" style coding interviews over the web, but I couldn't find any. So I did what any self-respecting programmer would do. I wrote one.

Man, was it worth it! I schedule my initial technical screenings with job applicants in 15-minute blocks. I'm usually done in 5-10 minutes, sadly. I schedule an actual interview with them if they can at least write simple a 10-line program. That doesn't happen often, but at least I don't have to waste a whole lot of time anymore.

Mike adds a disclaimer that his homegrown coding interview tool isn't meant to show off his coding prowess. He needed a tool, so he wrote one -- and thoughtfully shared it with us. There might well be others out there; what online tools do you use to screen programmers?

Three years later, I'm still wondering: why do people who can't write a simple program even entertain the idea they can get jobs as working programmers? Clearly, some of them must be succeeding. Which means our industry-wide interviewing standards for programmers are woefully inadequate, and that's a disgrace. It's degrading to every working programmer.

At least bad programmers can be educated; non-programming programmers are not only hopeless but also cheapen the careers of everyone around them. They must be eradicated, starting with simple technical programming tests that should be a part of every programmer interview.