While reading The Daily Grind from Larkware I found myself reading through a couple of articles (here and here) on programmers not being able to program. This obviously caught my interest as I feel I’ve worked with my fair share of these “programmers” in the past. It got me thinking about how to determine whether or not someone is good in an interview, how their background affects the way they perform when they start working as a developer, and whether or not having N years of experience actually means N years of experience or simply N lots of 1 years experience. More on this later.

I’ve blogged in the past about what I think makes a good developer, the differences between developers and programmers, self-learning of important things such as code security, and I even mentioned a few points while asking if you were any good. These posts, along with my recent one about OO coding, should give you a good idea of my opinion of the vast majority of developers out there at the moment.

If you consider the facts about where people come from, and how they get here, it’s no wonder that I have such an opinion. Have a read of this article to see the kinds of problems that computer science students are unable to solve. From the article:

An example of a Fizz-Buzz question is the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print Fizz instead of the number and for the multiples of five print Buzz. For numbers which are multiples of both three and five print FizzBuzz.

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary ? - the majority of comp sci graduates cant. Ive also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

You have got to be kidding me?!

I think this highlights the fact that a lot of people who go through I.T. and Computer Science courses don’t really understand or appreciate the level of problem solving skills required to make them an asset to a software development company. It also proves that experience isn’t necessarily all it’s cracked up to be (see my final point in this post).

Is programming about the syntax? Pff… anyone can learn syntax. Is it about how many languages you know? Pff… anyone can learn another language. I think it’s about being resourceful, being dedicated, being a cognitive thinker, and being a good problem solver. I would hire someone with no background in software who manages to map out solutions to problems they have never seen before without shitting themselves in the process over someone who’s got N years experience with X different languages and technologies that just can’t solve a simple problem by themselves. Don’t laugh, those people are out there! They may even be working alongside you (they could be you! :) .. or me!).

I think it’d be a bit unfair to list a few examples of people I know fit into this category of programmer, and it’s not really necessary anyway. But I will say they’re everywhere. So how do you weed them out before giving them a job? Is the idea of “FizzBuzz” enough? Are technical questions and programming problems in interviews the best way of finding out a programmers ability?

To be honest, I’ve got mixed feelings about this. I’ve been in interviews in the past where the questions are so hard that only someone with prior intimate knowledge of the problem space would be able to answer properly. I’ve had interviews where the questions were incredibly easy, to the point where I’ve questioned the level of the position I was applying for. I’ve had interviews where I’ve been asked some extremely obscure questions that just don’t relate to anything!

I can see how one of these types of questions can get different information about the interviewee.

• In the first case the interviewer probably doesn’t expect the candidate to be able to answer the question properly. Instead they’re looking at the approach that the candidate is taking to attempt to come up with a solution while monitoring how he/she performs under pressure and deals with the stress of having the interviewer wait for them to produce a solution.
• In the second case the interviewer is looking to see if the candidate responds by saying “wow, that was surprisingly easy”. If they don’t then chances are you’ve got someone who is looking for a cushy job, or who is grateful that the problem was so simple!
• In the third case the candidate’s though processes are being monitored and their actions reviewed while they’re thrown into a problem space that they couldn’t possibly fathom as part of their job.

Is there a “wrong” question for an interview? No, I don’t think so. I think most questions are appropriate for interviews so long as you get the required information out of the candidate in using them. If the question isn’t designed to extract the required type of information then don’t ask it! Candidates themselves should be prepared to face a plethora of topics in an interview, and if they can’t stand the heat then they shouldn’t be in the kitchen (I think I’ve said that before).

I think that wannabe developers need to understand that Software Development isn’t a free ride. It’s not a guarantee of a $1mill/year salary. It’s not a cushy field to get a job in. It’s hard to be recognised and you have work your tits off if you want to get somewhere in the field. It may do you good to know that …

• … understanding 50% of a programming language and using it to hack a few basic applications together … or
• … making a database or reporting application using MS Excel or MS Access … or
• … using VB to “write” an application which let’s you keep track of your own budget … or
• … writing a few JavaScript widges … or
• … doing a few assignments at university … or
• … creating a game trainer/crack … or
• … scripting a few programs to make your general computing life easier … or
• … anything like the previous points …

… does not make you a developer! Your aptitude, your problem solving, your resourcefulness and your love of challenges are what aid you in becoming a developer.

Finally I’d like to just recap a point I made earlier:

…whether or not having N years of experience actually means N years of experience or simply N lots of 1 years experience…

There are people out there who have worked in the industry for years and for each year they’ve looked to improve themselves, keep up to date with technologies, languages, best practices, patterns, platforms and insert other buzzword here. They love their tech, and they work very hard to make sure that it doesn’t outpace them. These are the kind of people who have a 1:1 ratio of experience years to work years, and these are the kinds of people that you should hire!

I’ve found a large percentage of the developers that I’ve had the pleasure of dealing with have a ratio of 1:3 or 1:4 - meaning that they’ve had that one year of experience three or four times. There is a big difference.

What do you guys think? :)