4 ms·

I think it's important to measure what's actually relevant to the job. If the job entails large periods of coding on the whiteboard, then yes, it's a perfect m

I think it's important to measure what's actually relevant to the job. If the job entails large periods of coding on the whiteboard, then yes, it's a perfect metric. If, however, the job requires careful consideration of dependencies, time domain, and, yes, edge cases - then you are NOT testing for that. Lock the candidate in a room and give a few hours to let her to produce the result would be a better measurement.

UncleMeat 8y ago
When I do whiteboard interviews I want a little bit of code because I'm stunned by the number of people who can't write a loop. But mostly I want to see the design process. I ask for a simplified version of a real feature that has an algorithmic core. This lets us code something but lets us discuss all sorts of edge cases and real world complexities that would come up in a true deployment. Lots of interviewers suck. That isn't a property of whiteboard interviews.
- java-man 8y ago
  so let's discuss the edge cases. let's operate with abstract concepts rather than actually write code.
- spike021 8y ago
  >I'm stunned by the number of people who can't write a loop I won't say this is you, but it's funny the number of people who will interview and say something like this and then still give a non-trivial problem/question to whiteboard. Reminds me of a guy who interviewed me several months ago at a place in Mountain View (not Google, but another). He started by asking me to create an object with a couple attributes. Then he slowly began to add to the problem by asking for X, then Y, then Z. Little by little, the code became more complex because he wanted iteration, etc. He would say "I just want to know that you're able to code." Later on, I found out he didn't like what I wrote, meanwhile all the basic elements of coding he wanted I was able to add without any problems and I met his specs. If there's a "communication issue" in whiteboarding, perhaps the interviewees shouldn't shoulder all of the blame. Perhaps the interviewers need to temper their expectations and learn to communicate them better, because obviously there is some disconnect in a situation like this, and it's not the first time I've seen this before.

UncleMeat 8y ago

When I do whiteboard interviews I want a little bit of code because I'm stunned by the number of people who can't write a loop. But mostly I want to see the design process. I ask for a simplified version of a real feature that has an algorithmic core. This lets us code something but lets us discuss all sorts of edge cases and real world complexities that would come up in a true deployment. Lots of interviewers suck. That isn't a property of whiteboard interviews.

java-man 8y ago
so let's discuss the edge cases. let's operate with abstract concepts rather than actually write code.
spike021 8y ago
>I'm stunned by the number of people who can't write a loop I won't say this is you, but it's funny the number of people who will interview and say something like this and then still give a non-trivial problem/question to whiteboard. Reminds me of a guy who interviewed me several months ago at a place in Mountain View (not Google, but another). He started by asking me to create an object with a couple attributes. Then he slowly began to add to the problem by asking for X, then Y, then Z. Little by little, the code became more complex because he wanted iteration, etc. He would say "I just want to know that you're able to code." Later on, I found out he didn't like what I wrote, meanwhile all the basic elements of coding he wanted I was able to add without any problems and I met his specs. If there's a "communication issue" in whiteboarding, perhaps the interviewees shouldn't shoulder all of the blame. Perhaps the interviewers need to temper their expectations and learn to communicate them better, because obviously there is some disconnect in a situation like this, and it's not the first time I've seen this before.