3 ms·

To me, it's not about the code on a whiteboard vs a computer and correctness. It's about the thought process when breaking down a problem and the ability to or

To me, it's not about the code on a whiteboard vs a computer and correctness. It's about the thought process when breaking down a problem and the ability to organize and communicate their thoughts. It's also about exploring a problem space. How carefully does an engineer consider edge cases? What kinds of things are important to them? A whiteboard to me is a much simpler and accessible medium through which to explore a problem vs setting up an environment and having to type code and dealing with all the minutiae that comes with actual development. Of course, it isn't the ultimate method of evaluating a candidate but it's certainly valuable.

java-man 8y ago
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.
sgslo 8y ago
If the goal is to test the thought process why not give interviee a self-directed project then ask them to present a 10 minute talk about it? You get some code written to verify the engineer can build something, plus you get confirmation that they can organize their thoughts and effectively communicate them to another engineer. Isn't that a more realistic scenario? How often do you give an (employed) engineer a task then ask them to immediately explain what they'll do to implement it?
- Retra 8y ago
  It is more realistic, but you can't really expect someone to be novel, and if they're not being novel, you should expect someone else to solve the problem. So this method has problems, and it kind of demands payment for results.
- solipsism 8y ago
  I'm confused by what you mean by self-directed. Would you give the person a specific problem to solve? Or would they be coming up with both the problem and the solution?
- ep103 8y ago
  Simple, I want them to work on the same topic as other engineers I've interviewed, so I can benchmark them against each other, and ensure the topic is close to what we work on, and not just what the candidate happens to know a lot about.
LaserToy 8y ago
How many times did you solve a real problem with capturing all the edge cases in less than 45 minutes?

java-man 8y ago

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.

sgslo 8y ago

If the goal is to test the thought process why not give interviee a self-directed project then ask them to present a 10 minute talk about it? You get some code written to verify the engineer can build something, plus you get confirmation that they can organize their thoughts and effectively communicate them to another engineer. Isn't that a more realistic scenario? How often do you give an (employed) engineer a task then ask them to immediately explain what they'll do to implement it?

Retra 8y ago
It is more realistic, but you can't really expect someone to be novel, and if they're not being novel, you should expect someone else to solve the problem. So this method has problems, and it kind of demands payment for results.
solipsism 8y ago
I'm confused by what you mean by self-directed. Would you give the person a specific problem to solve? Or would they be coming up with both the problem and the solution?
ep103 8y ago
Simple, I want them to work on the same topic as other engineers I've interviewed, so I can benchmark them against each other, and ensure the topic is close to what we work on, and not just what the candidate happens to know a lot about.

LaserToy 8y ago

How many times did you solve a real problem with capturing all the edge cases in less than 45 minutes?