4 ms·

Whiteboard interviews don't have to be ineffective. But empirical evidence suggests that companies greatly overestimate their ability to conduct them properly.

pmiller2 9y ago
So, what's a properly-conducted whiteboard interview look like?
- milesvp 9y ago
  Mostly talking about previous experience and especially any projects they were persoanally interested in talking about. I find there is only one thing you need to ensure a new hire can handle to avoid the major fakers. Give them a simple problem that requires a for loop. Usually it takes up like 5 minutes of the interview. I started asking it when I realized that the weakest people on my team would get stuck talking about problems that were simple iterations, they'd spend days trying to avoid a simple 'for foo in bar' coding solution. These were people who could program is the weirdest thing too. Fizzbuzz has become sort of a joke meme over the years but I've found Steve Yegge's core idea to be true, and you can see the deer in headlights with even the simplest code problem. So now it's all I do. Whiteboard coding is unnatural enough as it is, there's no reason to haze when all you care about is will they get hung up on stupid trivial things. Most code is basic CRUD there is no reason to ask about b-trees or tris, let alone implement them. If I feel the need to raise the bar even higher, I may include a simple pointer based question, since I've come to notice that indirection another concept that weaker coworkers struggle with. But the problem here, is that pointers just aren't relevant to the majority of what devs do these days, and modern languages do well to hide their usage which means fewer candidates will even have worked in a language like C. So you're likely to get a lot more false negatives. And interviews are stupidly expensive so you really want to avoid false negatives. For reference I work for a company with less than 1000 employees, serving web traffic that needs to handle 2000req/s peak 1000req/s sustained. There is little we do that doesn't fall under basic CRUD. Our biggest tech challenge is cache invalidation, followed by 3rd party API timeouts.

pmiller2 9y ago

So, what's a properly-conducted whiteboard interview look like?

milesvp 9y ago
Mostly talking about previous experience and especially any projects they were persoanally interested in talking about. I find there is only one thing you need to ensure a new hire can handle to avoid the major fakers. Give them a simple problem that requires a for loop. Usually it takes up like 5 minutes of the interview. I started asking it when I realized that the weakest people on my team would get stuck talking about problems that were simple iterations, they'd spend days trying to avoid a simple 'for foo in bar' coding solution. These were people who could program is the weirdest thing too. Fizzbuzz has become sort of a joke meme over the years but I've found Steve Yegge's core idea to be true, and you can see the deer in headlights with even the simplest code problem. So now it's all I do. Whiteboard coding is unnatural enough as it is, there's no reason to haze when all you care about is will they get hung up on stupid trivial things. Most code is basic CRUD there is no reason to ask about b-trees or tris, let alone implement them. If I feel the need to raise the bar even higher, I may include a simple pointer based question, since I've come to notice that indirection another concept that weaker coworkers struggle with. But the problem here, is that pointers just aren't relevant to the majority of what devs do these days, and modern languages do well to hide their usage which means fewer candidates will even have worked in a language like C. So you're likely to get a lot more false negatives. And interviews are stupidly expensive so you really want to avoid false negatives. For reference I work for a company with less than 1000 employees, serving web traffic that needs to handle 2000req/s peak 1000req/s sustained. There is little we do that doesn't fall under basic CRUD. Our biggest tech challenge is cache invalidation, followed by 3rd party API timeouts.