6 ms·

We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. This is meant as

by Tobani 8y ago

We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. This is meant as more of a conversation, we're less concerned about getting to the "right, fastest, or most optimized" answer. Not a hard problem, no mindgames, no syntax rules, and no complicated pre-known algorithm work other than an if and a loop. Let's just talk about some pseudocode. We've never rejected somebody for having a "bad" answer, because they were able to at least talk about what they're doing. We have had people flat out refuse to even try, and that seems like a pretty big red flag.

spike021 8y ago
That sounds like a much better way of handling a whiteboard problem. In my most recent on-site interviews, my interview would be in a room with full floor to ceiling glass windows, the next interviewer would come in, ask one or two personal questions, and then either cut me off after a couple minutes or just simply say "we're going to move on to the whiteboard now, do this". Meanwhile people are walking by staring into the room, looking at the whiteboard, etc. Which is just too rigid, IMO. When I interview a candidate, I want to know that they'll be able to work together with myself and my current teammates as a team. So I would rather do something similar to what you described.
- Tobani 8y ago
  Yeah, that's the trick. It isn't a technical exercise really. Its really a communication/team fit test.
pkteison 8y ago
Every time an interviewer has told me something like this, they then nitpick syntax and appear to be primarily concerned with "does my whiteboard code compile" sorts of problems. And getting stuck / asking for help feels like I get docked for getting stuck. Same with less optimized. So it's hard to trust such an explanation - clearly my interview would be better if I came up with the perfectly optimized solution, or gave a lecture on the options rather than trying to discuss options. So it seems to me entirely reasonable to still be nervous. Mind you, I don't have a better answer, but I don't think just explaining that suboptimal is ok and it's a discussion really helps.
- cakes 8y ago
  This is generally the same experience I have had. I'll even talk through the assumptions (e.g. "Can we assume I know how to do argument checking?") and then after I've done the heavy-lifting of the problem-solving I'm now discussing how I didn't do something I brought up as an assumption. Also, generally, if I'm whiteboarding in front of my coworkers/team/etc. I'm discussing something I've thought about for more than the few moments I have to digest the question while standing at the board during an interview.
  - pmiller2 8y ago
    Writing down the assumptions can help.
  - hvidgaard 8y ago
    Even if you didn't say > Can we assume I know how to do argument checking? I would probably question you at some point about a particular value of an argument and almost all candidates will get points for thinking out load that of course a NULL would get it crashing and that a simple check could stop it. Then it leads to discussion about how it should be handled. Sometimes a NULL means the program should cast an exception, other times it should just return without any side effect. IMO the hate for whiteboard questions is really a symptom of poor interview technique.
- amzn_82582 8y ago
  Maybe I was just lucky, but I interviewed with google and dropbox recently and both companies gave me laptops to type in, did not ask me once about if my code compiled, didn't comment on my style, nor did I have to perfectly know the standard library (for google, they told me to just guess at the random library functions and I also forgot some of the functions names for a set. For dropbox, one of the guys re-explained to me semaphore functions and how they worked since I forgot since it had been so long since I used them in college). I passed both. Granted, I will give you that optimized code has definitely been important. One of those interviews even had me use a bit array (at least I think it was that) to efficiently a store a list of booleans but at least they gave me the relevant function calls to use an already implemented one.
philwelch 8y ago
As a candidate, to me, that sounds a lot like, "we're going to do the same things we would normally do in a technical interview, but we're going to evaluate you based on random, arbitrary, subjective criteria that you will never know about rather than your actual level of skill."
zebraflask 8y ago
I'll bite: yes, if there's rapport and the candidate doesn't feel caught off-guard or needlessly pressured. If it's whiteboarding like you'd whiteboard while on the job with your coworkers, that's a good idea that can tell you a lot about a candidate. Unfortunately, in my experience, that doesn't seem to happen very often. A lot of people seem to treat it as an adversarial process or expect, for lack of a better description, a "performance" over contrived problems. I've had my share of the second kind, which were without exception some of the most unpleasant interviews I've ever gone on.
dingo_bat 8y ago
> We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. This is meant as more of a conversation, we're less concerned about getting to the "right, fastest, or most optimized" answer. Not a hard problem, no mindgames, no syntax rules, and no complicated pre-known algorithm work other than an if and a loop. Let's just talk about some pseudocode. If only all interviewers were like you.
- gautamdivgi 8y ago
  We do the same thing as well. As long as the candidate can explain their abstractions in pseudo code we are good. We also keep to a 1-1 between interviewer and candidate so that the candidate isn’t intimidated. I’ve interviewed at Facebook as well and although the interview was not successful I have never been nitpicked about syntax and compilabiltiy/runnability of my whiteboard solutions. I came off with a very healthy appreciation of the way they try to engage the candidate and reduce stress.
itronitron 8y ago
You are asking the candidate to compartmentalize their thoughts to solve a toy problem during a period of time when they are attempting to put various nascent clues about your organization together in order to form a better understanding and to identify how they can provide value / fit into the flow. Fizz-buzz tests have their place, but I think an onsite interview is past that point. In general I have found that white board exercises don't allow me to either understand or convey how I can apply my expertise to provide value for the organization.
- Tobani 8y ago
  Agreed. For us this is a communications/team fit exercise and not a technical exercise. It has done a good job of filtering out bad fits, like the guy who refused to talk to the women on our team regarding anything technical.
qudat 8y ago
> We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. Except at the end of the day this is an interview, you are judging their answers and evaluating their performance. I have been part of white boarding sessions like this and it does not reduce anxiety and still feels completely removed from what I actually do on a daily basis.
- Tobani 8y ago
  Not judging their answers. The only thing we're judging is their ability to communicate in a group setting similar to what happens on the team on a regular basis. We at least on a weekly basis somebody has some small problem they need help working through, it generally ends up being diagraming or pseudo-coding to figure out the best approach. If somebody can only participate by hiding in a corner typing out code, then the process worked for both sides.

by Tobani 8y ago

spike021 8y ago

That sounds like a much better way of handling a whiteboard problem. In my most recent on-site interviews, my interview would be in a room with full floor to ceiling glass windows, the next interviewer would come in, ask one or two personal questions, and then either cut me off after a couple minutes or just simply say "we're going to move on to the whiteboard now, do this". Meanwhile people are walking by staring into the room, looking at the whiteboard, etc. Which is just too rigid, IMO. When I interview a candidate, I want to know that they'll be able to work together with myself and my current teammates as a team. So I would rather do something similar to what you described.

Tobani 8y ago
Yeah, that's the trick. It isn't a technical exercise really. Its really a communication/team fit test.

pkteison 8y ago

Every time an interviewer has told me something like this, they then nitpick syntax and appear to be primarily concerned with "does my whiteboard code compile" sorts of problems. And getting stuck / asking for help feels like I get docked for getting stuck. Same with less optimized. So it's hard to trust such an explanation - clearly my interview would be better if I came up with the perfectly optimized solution, or gave a lecture on the options rather than trying to discuss options. So it seems to me entirely reasonable to still be nervous. Mind you, I don't have a better answer, but I don't think just explaining that suboptimal is ok and it's a discussion really helps.

cakes 8y ago
This is generally the same experience I have had. I'll even talk through the assumptions (e.g. "Can we assume I know how to do argument checking?") and then after I've done the heavy-lifting of the problem-solving I'm now discussing how I didn't do something I brought up as an assumption. Also, generally, if I'm whiteboarding in front of my coworkers/team/etc. I'm discussing something I've thought about for more than the few moments I have to digest the question while standing at the board during an interview.
- pmiller2 8y ago
  Writing down the assumptions can help.
- hvidgaard 8y ago
  Even if you didn't say > Can we assume I know how to do argument checking? I would probably question you at some point about a particular value of an argument and almost all candidates will get points for thinking out load that of course a NULL would get it crashing and that a simple check could stop it. Then it leads to discussion about how it should be handled. Sometimes a NULL means the program should cast an exception, other times it should just return without any side effect. IMO the hate for whiteboard questions is really a symptom of poor interview technique.
amzn_82582 8y ago
Maybe I was just lucky, but I interviewed with google and dropbox recently and both companies gave me laptops to type in, did not ask me once about if my code compiled, didn't comment on my style, nor did I have to perfectly know the standard library (for google, they told me to just guess at the random library functions and I also forgot some of the functions names for a set. For dropbox, one of the guys re-explained to me semaphore functions and how they worked since I forgot since it had been so long since I used them in college). I passed both. Granted, I will give you that optimized code has definitely been important. One of those interviews even had me use a bit array (at least I think it was that) to efficiently a store a list of booleans but at least they gave me the relevant function calls to use an already implemented one.

philwelch 8y ago

As a candidate, to me, that sounds a lot like, "we're going to do the same things we would normally do in a technical interview, but we're going to evaluate you based on random, arbitrary, subjective criteria that you will never know about rather than your actual level of skill."

zebraflask 8y ago

I'll bite: yes, if there's rapport and the candidate doesn't feel caught off-guard or needlessly pressured. If it's whiteboarding like you'd whiteboard while on the job with your coworkers, that's a good idea that can tell you a lot about a candidate. Unfortunately, in my experience, that doesn't seem to happen very often. A lot of people seem to treat it as an adversarial process or expect, for lack of a better description, a "performance" over contrived problems. I've had my share of the second kind, which were without exception some of the most unpleasant interviews I've ever gone on.

dingo_bat 8y ago

> We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. This is meant as more of a conversation, we're less concerned about getting to the "right, fastest, or most optimized" answer. Not a hard problem, no mindgames, no syntax rules, and no complicated pre-known algorithm work other than an if and a loop. Let's just talk about some pseudocode. If only all interviewers were like you.

gautamdivgi 8y ago
We do the same thing as well. As long as the candidate can explain their abstractions in pseudo code we are good. We also keep to a 1-1 between interviewer and candidate so that the candidate isn’t intimidated. I’ve interviewed at Facebook as well and although the interview was not successful I have never been nitpicked about syntax and compilabiltiy/runnability of my whiteboard solutions. I came off with a very healthy appreciation of the way they try to engage the candidate and reduce stress.

itronitron 8y ago

You are asking the candidate to compartmentalize their thoughts to solve a toy problem during a period of time when they are attempting to put various nascent clues about your organization together in order to form a better understanding and to identify how they can provide value / fit into the flow. Fizz-buzz tests have their place, but I think an onsite interview is past that point. In general I have found that white board exercises don't allow me to either understand or convey how I can apply my expertise to provide value for the organization.

Tobani 8y ago
Agreed. For us this is a communications/team fit exercise and not a technical exercise. It has done a good job of filtering out bad fits, like the guy who refused to talk to the women on our team regarding anything technical.

qudat 8y ago

> We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. Except at the end of the day this is an interview, you are judging their answers and evaluating their performance. I have been part of white boarding sessions like this and it does not reduce anxiety and still feels completely removed from what I actually do on a daily basis.

Tobani 8y ago
Not judging their answers. The only thing we're judging is their ability to communicate in a group setting similar to what happens on the team on a regular basis. We at least on a weekly basis somebody has some small problem they need help working through, it generally ends up being diagraming or pseudo-coding to figure out the best approach. If somebody can only participate by hiding in a corner typing out code, then the process worked for both sides.