If you can comment, I would be interested on the standard of coding that successful candidates exhibit once employed.
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.)
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.)