Last year, I interviewed a ton of programmers at work. Our interview process is a multi-layered approach; each layer acts as a defence intended to filter out candidates along the way as they run the gauntlet. The first line of defence is with our recruiters who makes first contact with the candidate, chats with them, and ask some simple technical questions. The second line of defence is the phone screen interview with one of our programmers. The final line of defence is the on-site interview where the candidate meets with several managers and programmers. The reason for all these hoops is because it's actually very expensive in terms of time and money when you get a bad candidate come through.
One day I get an e-mail from our recruiter informing me that an on-site interview was being scheduled. I took a look at the candidate's resume and found something quite peculiar, the candidate had a bachelor's degree in writing, and a master degree in journalism. Don't get me wrong, the degrees are perfectly fine, but this isn't the usual educational background that I see for programmers. Interestingly enough, the candidate had also published several books about a programming language that use. I assumed that if you could write a book about a subject and have it published, then you would be a domain expert in that area. So this was going to be an interesting interview.
The interview day finally comes, and it's my turn to interview the candidate. I do my usual introduction, and then immediately ask him what his story was. How does a writing major transition to the world of computer science? The candidate asserts that writing good software and writing are actually very similar disciplines, it all comes down to syntax and grammar, and being able to express yourself creatively. A part of me was somewhat skeptical about this analogy because I remember all those painful math and algorithm courses that I took in university. Is every writer out there really a closet programmer just waiting to be discovered?
I jump into the technical portion of my interview and ask the candidate to write some code on the white board. I present a fairly simple programming task and the candidate seems to be stumbling through it. I go through a couple questions related to what he had written on the white board, and asked how he could optimize the code to run faster, and he was completely stuck. I look at one of the functions he had used on the board and asked him if he could implement a simple naive version of it by hand, and he could not. Long story short, the technical portion of the interview didn't go well at all.
I left the room fairly unimpressed. I met up with a colleague who had interviewed the candidate earlier just to trade notes. I asked my colleague if he had read the candidate's book before. My colleague said he read snippets of it on Amazon.com, and it was absolutely garbage. I thought to myself, how could a bad programming book possibly be published? In academia, when you publish a paper, they're typically peer-reviewed which ensures a certain level of quality. My colleague laughed at my naivety; he explained that book publishers/editors aren't necessarily domain experts in good programming practices, and that's why there are a lot of really bad programming books out there. Just because you could publish a book about programming doesn't mean you're a good programmer.
This was an eye opening experience, and I definitely learned something that day.
