I hear a lot of talk that coding interviews are a waste of time and don’t really tell a potential employer anything. Well, I disagree and here’s why:
It’s like role playing, but different – Every interview I’ve had has asked some variant of “Close me on a job w/ XYZ company” Which asks me to go through who I “close” an offer. Isn’t a coding interview the same thing? I mean, if I can’t close than I can’t recruit right? If you can’t code up some simple problem on the fly…..um, well, yeah…exactly.
Thought process – It’s not about coming up with the master solution…although it helps. What people are trying to assess is your thought process. Did this person attack the problem in a thoughtful manner? Did they use the right algorithm? Data structure ok? Sloppy code is forgivable if you’re solving the problem the right way.
Bugs Kill – The old saying is that your average engineer produces zero lines of code a day b/c of the amount of bugs created. So, um if this is true why even build software? Well, if this is true then you have to try and find the engineers that don’t break the code. How? Coding interviews. Ask them how to improve performance, complexity, testing philosophy etc etc and try to reduce the odds of hiring the engineer who breaks your code.
Hiring engineers is hard, I mean really hard. Take a look at a few resumes. They are all covered in buzzwords and everyone claims to be an expert in Java, C++ and a few other things I’ m not even sure exist. In my opinion, the only way to truly figure out who knows their stuff and who doesn’t is to get them on the whiteboard and ask them to code up a solution.