One data point that I obtained for the book (but didn’t quite include in the book because it was too programmer centric) was based on 22 job interviews for programming positions I conducted for one of my clients over a period of two months.
Though this is hardly a considerable sample size, it did reveal some interesting facts about programmers. There were two seemingly disconnected questions that we asked at completely different moments of time during the interview:
- Talk about a few things in your current organization or manager that you don’t like / aren’t happy with.
- Solve a simple programming problem (one that was much easier than the famous Fizz Buzz problem).
The goal was to study the correlation between whining and coding abilities. Here’s a subset of the data we collected (of course I wasn’t carrying stop watches in the interviews so the minutes have been rounded up to an interval of 1):
Even though there are some exceptions in the above data set if you look at the graph what’s evident is that there seems to be a strong co-relation between whining and being able to solve ridiculously simple programming problems.
That was interesting. But what was even more interesting was the actual program the candidates were being asked to solve. If Jeff Atwood wonders why programmers can’t program, when they can’t solve Fizz Buzz; here’s a problem that is much more easier than Fizz Buzz and yet:
- About 14% just couldn’t solve the problem in less then 10 minutes – which is when we moved on to the next question.
- About 40% took more than 5 minutes to solve the problem and / or had to be corrected more than once.
- Only about 14% could solve this problem in 2 minutes or less.
- About 82% had to be corrected at-least once before they solved the problem. (which means they actually got it wrong the first time around!)
And the problem they were solving?
Print 100 to 1.
That’s it.
That was the question.
The Catch?
You need to start with “for(int i=0;” and continue from there – you cannot write anything before “for(int i=0;” and you can’t use two loops.
[Update: This is supposed to be a code snippet which already exists inside a function, so you can safely assume that inclusion of headers and declaration of the functions etc. is already done for you and you don’t need to worry about that.]
Go ahead. Try it out. The answer really won’t take you more than 2 minutes and should not take more than 4 lines of code including the curly braces but you can write as many lines as you want.
If you get the right output without mistakes in a reasonable amount of time we consider the answer correct.
Go on. Try it. And once you’ve solved it – go on and make it a part of your interview process and see countless programmers fumble, take really long pauses, struggle and even give up on the question.
Personally, I came across two programmers who said they could not do it because the question was too complicated after over 10 minutes of struggling with the problem.
While this little experiment establishes correlation between whining and skills it doesn’t establish any causation. In other words the data doesn’t really tell us if programmers whine because they just don’t have the skillsets to do their job, or programmers don’t have the skillsets to do their job because they whine.
Maybe our programmers are not skilled because they whine a lot or maybe they whine a lot because we’ve lowered our bars of what we expect from our programmers and don’t demand or challenge them enough to even practice the most basic programming skills.
Either ways the sad reality of where the IT industry stands today is that you don’t even need Fizz Buzz to differentiate a bad non-programmer from a good one – Just asking them to print 100 to 1 is usually good enough.
[Update: A lot of folks seemed to get an idea that this is a black and white question and that you can make a hiring decision based on this. It’s not. But it does give you an important data point to evaluate someone. For example, if someone clears this question and then fumbles at other basics it might be a reason to not hire him / her. At the same time if someone doesn’t answer this and go on to answers other complex algorithmic questions really well, you may decide to hire him / her. Putting the candidate at ease is also important here. The candidates should not be asked or pushed to solve the question in less than 2 minutes. The goal here isn’t to stress out the candidates. The goal is to watch them think about and solve a simple problem. Merely present the problem to them and watch their approach and time taken. Couple that up with their tendency to whine and the question provides some very useful insights about a person’s approach towards solving problems and their ability to ship.]
[Update: Thanks to the folks who were rightly annoyed by the confusing visualization / chart done in the original post and pointed out how confusing that data visualization was. Special thanks to Jacob for creating the scatterplot using the same dataset. Post updated with the scatterplot.]
