Debunking the Google Interview Myth

So if some questions (like the "why are manhole covers round") are definitely fake, and others seem very weird (like the dead beef one), isn't is more likely that that question is fake too?

I just got done doing a series of 10 1-hour interviews for contractors for an enterprise Java web application contract lasting about 6 months. Only 2-3 of them could write correct Java on a white board for simple questions. We had three who weren't even close to Java syntax. Code quality seemed to be directly relational to algorithm quality, in that those with better syntax also knew how to solve the algorithms best, and those with terrible syntax were way off on the algorithms.

Up until we asked these candidates to write code on the board, a few of them sounded like great hires. They could rattle on about design decisions and enterprise web application stacks, about configuration and organization. But when it came to the white board at least one of them just stood there and left it mostly blank.

Some of the positions here have had interviews where the candidate is expected to write code but only one, if even that, interviewer asked to see any code. And even then the managers don't seem too worried when I tell them the person can't code, because everyone else likes them so much.

Good ones write good code; the ones we shouldn't have hired write poor code or don't code at all. As for how to tell the difference, I pay a lot of attention to candidates' questions, comments, and attitude while writing code. That part carries over pretty directly to how they do their real job and how pleasant they are to work with. As for quality of code, my rough impression is that the more meaningful details they take care of in their whiteboard code, the more productive they are. Getting syntax and library function names right or wrong doesn't tell you much (except how recently they wrote code that used that syntax or those functions) but getting other details right does matter.

Which details matter is a matter of judgment. My attitude is that some errors are trivial but should be corrected if attention is called to them. For example, off-by-one errors in array indices are easy to miss on a whiteboard if they only affect one line of code or just make the output a little incorrect -- that's no big deal -- but when a candidate gets stuck or confused because of an off-by-one error he made a few lines up, he should be able to figure it out, correct the error, and correct any related errors.

Good things to watch out for (besides asking good questions to make sure the problem is well specified):

1. The candidate doesn't start writing a complete solution without having a decent idea where it's going. If he doesn't see a solution immediately, he takes some time to understand the problem, possibly working an example by hand, sketching out possible solutions, or talking through the problem verbally.

2. The candidate draws logical inferences about his own code. "Oops, this function signature is wrong, because in these two cases the same arguments are passed, but the output needs to be different. I need to pass in more information."

3. If the candidate takes the wrong path, he backs up as far as necessary to get back on the right track. He reminds himself of the problem statement and reevaluates his decisions up to that point.

Bad things to watch out for (besides having a bad attitude or failing to ask questions):

1. The candidate launches right into coding a solution without understanding how the problem can be solved. (Those candidates usually end up boxing themselves in, so they really better be good at backing up and starting fresh.)

2. The candidate spends a long time trying to impossible code, such as trying to implement the body of a function when the arguments he has specified for it don't contain enough information.

3. If the candidate takes the wrong path, he doesn't back up far enough to recover. For example, he doesn't question anything he decided more than five minutes ago, so he starts to treat his initial steps in solving the problem as if they were part of the problem statement. (I have seen the opposite mistake also, where a candidate encounters a problem that is clearly local to a small part of his code, but he interprets it as invalidating his whole approach. That mistake is usually just a mistake; people are going to make mistakes under pressure. It doesn't show a lack of intellectual flexibility like the opposite behavior. Depending on the circumstances I might interpret it as a lack of persistence, but usually not.)