4 ms·

I absolutely agree that whiteboarding is a skill that requires practice. That said, with a reasonable interviewer, the first couple things you're discussing rea

I absolutely agree that whiteboarding is a skill that requires practice. That said, with a reasonable interviewer, the first couple things you're discussing really don't matter. The trick is to understand that no one cares if you're actually writing working code, and that the important thing is communicating your intentions and process. > There is no insert. This really isn't a problem. If you need to insert a line, in most cases you can just draw an arrow and then describe what you forgot to do there. Code may not even be necessary. Anyway, an arrow is fine. > There is no context driven autocomplete or quick method lookup Again, not really a problem. Just say "I forget the method name here, I'm just going to assume it's called 'append'" (or some other appropriate name). No reasonable interviewer cares in the slightest as long as it's clear you know what you're doing and it makes sense. > If you code iteratively the whiteboard is not your friend. This is absolutely an issue. Everyone codes iteratively though. Successful whiteboarders learn to do the iterative part of coding verbally instead of in code. You talk through the algorithm you're going to implement, and refine your plan in words, and then only when you've got a solution you're happy with do you pick up the marker. As a side benefit, this demonstrates your thought process much better than coding would. Actually, this is just a better flow even for development on your own computer. Once you develop the skill, you'll find that a little more planning time before you touch the keyboard almost always leads to faster implementation overall.

wilc0 10y ago
> The trick is to understand that no one cares if you're actually writing working code, and that the important thing is communicating your intentions and process. This is absolutely not true. I've interviewed at many major companies (Google, Apple, Snapchat, etc.) and they all say at the beginning "Make sure you have working code". They don't necessarily care about syntax errors or spelling errors, but they absolutely want working code.
- nolemurs 10y ago
  > They don't necessarily care about syntax errors or spelling errors, but they absolutely want working code. I'm not sure how code with "syntax or spelling errors" qualifies as "working code." The fact that they don't care about those things is pretty much the exact thing I was trying to communicate. Other things they probably don't care about: unimplemented placeholder functions (they might ask you to go back and fill those in if they thing it would be informative and there's time), or misremembered function/method names (though it's important to communicate that you know you don't remember). I mean, obviously they do want code that demonstrates a well thought out solution to the problem. But no one expects that you could just copy it into a text file compile it, and have it run - that's what I meant when I said no one cares if you're writing working code.

wilc0 10y ago

> The trick is to understand that no one cares if you're actually writing working code, and that the important thing is communicating your intentions and process. This is absolutely not true. I've interviewed at many major companies (Google, Apple, Snapchat, etc.) and they all say at the beginning "Make sure you have working code". They don't necessarily care about syntax errors or spelling errors, but they absolutely want working code.

nolemurs 10y ago
> They don't necessarily care about syntax errors or spelling errors, but they absolutely want working code. I'm not sure how code with "syntax or spelling errors" qualifies as "working code." The fact that they don't care about those things is pretty much the exact thing I was trying to communicate. Other things they probably don't care about: unimplemented placeholder functions (they might ask you to go back and fill those in if they thing it would be informative and there's time), or misremembered function/method names (though it's important to communicate that you know you don't remember). I mean, obviously they do want code that demonstrates a well thought out solution to the problem. But no one expects that you could just copy it into a text file compile it, and have it run - that's what I meant when I said no one cares if you're writing working code.