4 ms·

Whiteboarding itself is a skill. What I learned the hard way: - There is no insert. If you need to go back and insert a line of code somewhere you must eithe

Whiteboarding itself is a skill. What I learned the hard way: - There is no insert. If you need to go back and insert a line of code somewhere you must either erase all the code below it to make room (then rewrite said code), or you draw a line from the insertion point to somewhere else on the white board and write the code there. For the former you waste a lot of time. For the later the code quickly becomes hard to follow. - There is no context driven autocomplete or quick method lookup. If you spend your entire day coding in one language and have done so for the last >3 years you should be fine. If you code in multiple languages and spend time with other tasks (devops for example), you might not realize how much you rely on this. - The white-boarding process works well (given previous two caveats) if you code in a linear style. If you code iteratively the whiteboard is not your friend. My recommendation to someone starting the interview process. Go buy a small whiteboard and use it to code solutions to interview questions you find online.

whazor 10y ago
I am assuming that you can use pseudocode
- sterex 10y ago
  Exactly! The above comment assumes that a linter will be run against the core on the white board. Jeez.
ryandrake 10y ago
All your points are good--and they are part of the overall problem with whiteboard coding: A whiteboard is not even close to a realistic modern development environment. How many times, for your job, have you had to code up a solution to a problem, even a trivial one: 1. Just given to you 5 seconds ago 2. With no access to documentation (paper, textbooks, offline or online resources) 3. With no access to mentors or colleagues 4. With an editor crippled as you described 5. Have to get it right within minutes? 6. And then have to defend your code against someone who's had plenty of time to think about the problem. I can tell you, throughout my programming career, the answer is "never".
- wilkystyle 10y ago
  This, to me, is the most important point. We make such a big deal about making sure our tests actually test the thing we care about; why aren't we doing the same thing with our interviewing processes?
nolemurs 10y ago
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.

whazor 10y ago

I am assuming that you can use pseudocode

sterex 10y ago
Exactly! The above comment assumes that a linter will be run against the core on the white board. Jeez.

ryandrake 10y ago

All your points are good--and they are part of the overall problem with whiteboard coding: A whiteboard is not even close to a realistic modern development environment. How many times, for your job, have you had to code up a solution to a problem, even a trivial one: 1. Just given to you 5 seconds ago 2. With no access to documentation (paper, textbooks, offline or online resources) 3. With no access to mentors or colleagues 4. With an editor crippled as you described 5. Have to get it right within minutes? 6. And then have to defend your code against someone who's had plenty of time to think about the problem. I can tell you, throughout my programming career, the answer is "never".

wilkystyle 10y ago
This, to me, is the most important point. We make such a big deal about making sure our tests actually test the thing we care about; why aren't we doing the same thing with our interviewing processes?

nolemurs 10y ago

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.