Solving Problems, You Better Learn How
It is astounding how many developers can write and maintain large enterprise systems dealing with all kinds of complex logic, database access, etc and cannot for the life of them solve a moderately difficult programming problem given in an interview in less than 30 minutes.
It is also astounding how many developers who can not write even a single line of code, can also fail at same problem, in exactly the same way.
Based on those two statements, your first assumption might be that asking someone to solve a programming problem as part of an interview would be a bad idea, because it isn’t really telling you if they are good and just crumble when asked to do something like this on the spot, or if they can’t program at all.
Let’s look at some possible numbers to see why this is wrong
In poker you can use a combination of pot odds and the likely holdings of your opponents to deduce in many situations whether or not you should call a bet.
Pot odds is simply a ratio of how much money is in the pot (what you can win), versus how much it will cost you to call the bet.
For example, if a pot contained $9 and I bet you $1, you would be getting 10:1 odds on your money for a call (you have to risk an additional dollar to potentially win 10.)
So in that example, if you have a better than 10% chance of winning, you are making a profitable play by calling.
I don’t have the exact numbers (actually I am just guessing at them from experience), but here is a realistic estimate:
- Good programmers – 60% can solve the problems
- Great programmers – 90% can solve the problems
- Don’t know how to program, lied on my resume – 1% can solve the problems by some sort of divination or black magic, or memorizing sequences of symbols which solve the problem.
Given some statistics like this, if you have someone pass this kind of a test, you can calculate the rough probability of which of the three groups they belong to.
- 40% chance they are Good
- 59.5% chance they are Great
- .5% chance they are a black magic practicing witch or warlock
- 99.5% chance they are either good or great
So, even though you may be throwing away some good candidates and some great ones, the chance of you getting someone who doesn’t know how to code at all is almost reduced to nothing. This is very important!
Why? Because if you hire someone who doesn’t know how to code at all, it will cost you a huge amount of money, but if you pass over someone who is great, but still end up getting someone else who is good or great it doesn’t really cost you anything except in the rare case that the great programmer failed out of the test and you ended up hiring a good one instead.
Even still, that is a small loss versus hiring someone who can’t write a lick of code.
I’ve talked about how I think having code in an interview is a good thing before, but now the numbers are here to back me up.
More and companies are realizing the truth about this situation and companies like Codility are popping up to offer a service to test candidates for you.
What this means for you?
You might not get asked to solve a problem or write code in your next interview, but there is a growing chance that you will.
You may think to yourself, ok even if I bomb the code writing part, I will do great on the rest of the interview and be able to convince them that I know how to write code, besides any company that would toss me out of the running for failing some stupid online test is a company I don’t want to work for anyway.
To that I say a company that doesn’t know how to do math is a company that you don’t want to work for. If my numbers are anything close to accurate, the mathematical best choice is to almost always throw out someone who fails the coding test.
The simple solution is to learn how to solve these kinds of problems. Learn how to write an algorithm under pressure in 30 minutes. It’s not that hard to practice and the skill will help you in many other areas of your career and probably your life in general.
I’ve written before on TopCoder as a great site to practice these kinds of problems, and if you haven’t checked it out that is a great place to start.
Another option is to get the book Programming Pearls. It is a bit dated, but has some nice programming problems for you to try to solve.
I’ll follow up this post in the coming weeks with some hints and tips on how to take a programming problem, break it down and finally code it. Learning how to do this properly can make some of the more difficult algorithm type problems very simple.
So get to it! Start learning how to solve programming problems. Reverse strings, sort linked lists, help grandma pick the highest yielding grandsons and a granddaughters to send Christmas cards to!
If you are following my back to basics series, don’t worry, it is still on. I’ll probably pick back up with it after the holidays.