I'll jump on the "ignore tip #4" wagon (as long as you mention that it's naïve, and immediately move on), but I've got beef with some of the rest too: 2: More

I'll jump on the "ignore tip #4" wagon (as long as you mention that it's naïve, and immediately move on), but I've got beef with some of the rest too: 2: More important than understanding what the problem is asking, is understanding why it's being asked. Do they want to see you come up with an interesting algorithm, or is it a simple matter of "does this young fellow know what a pointer is?" Figure this out, and you'll be able to cut your work in half, because you can avoid doing things the interviewer was never interested in seeing anyway. You can in most cases just ask straight out "you just want to see if I can flip bits correctly, don't you?" and get an honest answer. 5: Checking boundary conditions when coding on a whiteboard is bogus, unless that's the point of the problem, and not algorithmic complexity. If you're writing code with durability or atomicity constraints, or it's obviously a bit twiddling mess that was only asked to see if you can check for them, edge cases matter. If you're writing something complex at a high level, you should be able to get away with sweeping the null checks under the rug. 6: Some people (hi) can often keep track of a sizable number of invariants as they check over a bit of code, and this means they can run mental tests very quickly, that are often more thorough than running a few examples. It's reasonable and good to be able to do this (you'll be a great debugger), and a good interviewer won't discount you for it. In my case, I would do this mental check, prove to myself that it was right, then just say "ok, I'm convinced it's right, would you like me to sketch a proof, or run some examples?" If they want examples, you can use what you learned doing that quick check to generate examples that you think will hit the corner cases. You should really be prepared to prove it aloud, and then check some examples anyway, in case you forgot about some type of input (punctuation in the article's problem is a good example) 7: You should ask about the interviewer, partially to make the interviewer feel good getting to talk about herself, but mostly to find out as much as you can about her, and feel your way around what sorts of things you might be able to get away with in the interview, and what things she'll be hunting for. For this reason, you should ask these sorts of small talk-y questions before the bulk of the interview if possible, and use what you learn immediately to mentally prepare for the question, and to guess what sorts of questions you should ask, and what questions she'll be asking about your solution. (Passed their intern interview recently too, high five Locke)