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 can’t. I’ve 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?
March 6, 2007
My experience doesn’t extend to interviewing programmers… if I did our company would go broke!
But, give me a designer to interview and yes, there are definitely questions you can ask that let you know you are dealing with someone worth hiring.
In that, I think design may be easier to judge, because generally you will get techies that think they’re designers… but ask them what process they went through to get to a design outcome and they answer by talking about how they took the PSD and cut it up… which ve y clearly (for other designers) doesn’t answer the question. I guess that raises the question, can you dupe your interviewer if you know what language to use…
And one other point, it can be hard to critique the skill level of someone (again in design) if they have worked in a big company for several years and have only one or two major clients to showcase… so what I look for is someone that is active outside their work - via a blog, flickr, deviantArt or such…that kind of stuff will really let you know what someone is potentially capable of producing…
March 8, 2007
Look at me I can program!!!
Seriously though, you make a good point. I’ve recently moved jobs and went to a few interviews. Unlike a few years ago when I was less experienced, I was hardly grilled on a technical level, with interviewers sometimes assuming skills based on previous projects I’d worked on. The programming tests I was given were mainly tests of knowledge on obscure bits of C++ or trick questions with very little emphasis on day to day tasks or communication skills (something else which is vitally important in a good developer).
I’m not sure it really is possible to get a good handle on a person’s ability from an interview alone. You can certainly tell is they’re total crap, but if they’re good enough to talk the talk it gets more difficult. I guess this risk is why companies all have probation periods for the first few months.
March 8, 2007
Huh??? What the hell happened to the rest of my comment?
March 8, 2007
I dont know mate, that’s all I got! Plus I fixed up your blockquote stuff up
Feel free to repost with “the rest”
Tests in interview tend to be stupid like that. Who actually uses template metaprogramming in C++ for enterprise software dev? What game developer cares about threading issues in ASP.NET? One of the big issues here is the relevance of the question. If I’m going for a job as a mechanic, I don’t expect to be ask how to build jet engines. Sure, it might be ’similar’ in some ways, and more ‘high tech’, but it’s not relevant to me doing my job.
Keef, how do you separate the good from the bad? And why is it that there are so many coders who can’t code?
March 9, 2007
I think it interpreted the less than operator in the code I posted as the start of an html tag (I thought it might auto replace it with < but it didn’t). Anyway, it doesn’t matter as it was a mickey mouse example that I’d solved in a few mins. Maybe I should enter one of your proper code contests.
I think there are a lot of coders who “think” they can code, but actually can’t (very well). it may be because of the way a lot of people learn to program in the first place. Quite a few people learn (some) of a language, figure out how to bodge something useful together and stop learning there cos they think they can solve any problem.
I’m not sure how you separate the good from the bad at an interview. There are a lot of people who can talk the talk, but not walk the walk.
You need to see people approach some real world problems and see how they come out of it. For example, knowing the best way to detect a loop in a linked list or writing an optimised memcpy() isn’t that useful day to day, but (to pluck another example out of the air) the approach someone would use to debug a hard crash is.
March 9, 2007
That’s a fairly typical stance on people who are self-trained. As I mentioned in an earlier post about qualifications, I’ve found that a lot of self-taught coders don’t study the areas they find boring or hard, because they have no need when they feel they can solve the problem already using some other method.
Your point about real-world examples is quite key, but again they can be a bit of a bitch in interviews. The question you mentioned about hard crashes is one I faced in 3 of the 4 interviews I had for games programming. It’s a good question! Unfortunately it reminds me of the bug we had on my last day… do you remember that?
March 10, 2007
http://davidseah.com/archives/2007/03/05/building-a-talent-network-thoughts/ … slightly off topic, but in a way is a suggestion as to how to overcome the “is this guy any good” issue…
March 14, 2007
Only too well. I went and got your lunch for you from town cos you were so busy sorting it! ROAR!!!
March 14, 2007
On the self taught point, I condider myself mostly self taught. I first learned to code from about the age of 10 starting with BBC BASIC on my dad’s Acorn Electron (by a process of borrowing whatever programming books I could from the library to plough through + lots and lots of trial and error).
I did a CS course at Uni and was taught a handful of languages, some database scheme design (probably the most useful thing in the entire course - if I could remember half of it) and a bunch of very outdated software engineering techniques. The waterfall model was seen as “The one true way” with any lightweight agile iterative processes being portrayed as signs of poor requirements gathering. Very little actual coding architecture was taught. As you can see, I have a fairly dim view of the course I did, though didn’t know enough at the time to do anything about it.
I go through phases of reading a SE books (I should read a lot more). I’ve recently read Modern C++ Design, which has opened my mind a little on the use of templates in C++ and generic programming techniques in general (even for a game engine), though that’s a totally different topic.
Anyway, to get back to the point (rather than just telling my life story), I don’t necessarily think being self taught is a bad thing as long as the person is willing to expand that knowledge and learn about more than just whatever cool thing they specialise in. I’m as guilty of that as anyone, though I do try to make amends.
March 21, 2007
That last one is the key point mate. And that’s part of the reason why I think that Uni degrees are good in that you’re forced to learn the stuff you don’t necessarily have the interest in.
If you’re disciplined enough to do this yourself outside of formal study, then you’re well ahead of the rest!