Interviewing developers

time to read 3 min | 578 words

My post about two (PHP) code samples that I got from people that I interviewed got a lot of comments, so instead of answering them one by one, I am going to answer them here. The post had a two code samples, one from a coder with 8 years experience, the second from a sysadmin that wants to move to development. Suffice to say that the sample from the coder with 8 years under his belt is atrocious.

Mostly, the comments tended to be:

  • Why am I interviewing PHP programmers?

    My company is also doing head hunting / recruitment, interviewing people is part of the job.
  • The sysadmin code looks good on the surface, but it is has problems. (and then listing the problems, in many detailed and interesting ways).

    The sysadmin code is not perfect by any means, but it is structured, it shows basic understanding of how things work, and the rest can be handled. That guy can learn to write good code. That isn't code that I would write, or would accept in my projects, but that is a very good start for the first steps.

image But a lot of people said that the first code sample is a quick & dirty solution to the problem at hand, some actually took offence at the idea.

If I interview someone for a position that include working with code (in fact, if the CV include any programming language whatsoever), you write code, period. The reasoning is that there are plenty that can talk the talk, but literally can't code. And looking at your code means that you get a lot of insight on how that person write code and how they think.

Now, here is an observation, you tend to write code in the same way no matter in what scenarios you are. Writing sloppy code in an interview is something that is a strong indication for a sloppy coder. That is not the only indication that I use, but it is certainly a significant one.

Given a choice between an experienced sloppy coder and an inexperienced one, I know who I would rather hire.

Now, to those who claimed that such questions are insulting, I am usually trying to fit the question to the person that I am interviewing (so a team lead would get something more interesting), but the key thing to remember is that I am not looking at the solution itself, I am looking at everything that they have around that.

I want to say that code style isn't something that I considering, but that would be a lie. I expect that the candidate would have some sort of a code style, and that it would be internally consistent. Beyond that, I don't really care if it spaces vs. tabs and where the curly go. But if there isn't a coding style that the candidate adheres to, that is something quite alarming.

Oh, and here is a secret that would make the argument more interesting, I don't program in PHP. The last time that I had to use that was when I tried to modify a bug tracker in PHP, and that was about two and a half years ago (the dot operator for string concat drives me crazy).

Just to remind people, my purpose in posting that was to talk a bit the difference between "experience" and quality.