11 ms·

> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating con

> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? I hate this concept that if it's not typing code into an editor then it's not "real work". I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low. Now if this particular skill isn't interesting to an employer and they'd rather spend the time talking about some other candidate capability, that's a whole different story.

java-man 8y ago
even then, this is not what's being tested with the whiteboard. thinking and presenting are two separate skills, and, in my opinion, can rarely be executed at the same time.
- vymague 8y ago
  So if you're looking for someone who can execute both at the same time, whiteboard coding is ok?
  - swsieber 8y ago
    If your looking for someone who can think, code and present at the same time, yes.
- deleted 8y ago
  [deleted]
jdc 8y ago
The point is that the interview style in question overemphasizes on-the-spot responses. How is prowess in a game of "gotcha" an important indicator of engineering skill?
- munchbunny 8y ago
  I tend to agree with (what I think is) the sentiment of some of the respondents in the article: if your whiteboard interview is a game of gotcha, then the problem is your interviewer, not the whiteboard. I think the complaint that programmers pretty much never have to think about code under pressure is a fair criticism. The whiteboard really puts you on the spot. But if it's your company and your hiring managers are playing a game of gotcha on the whiteboard, you need better interviewers.
  - java-man 8y ago
    in a sense, I agree. this is a signal to the candidate that the interviewers do not fully understand what they are measuring. which also means the team might consist of people selected by using this metric. this is a good signal ;-)
  - ilikehurdles 8y ago
    State dependent learning is a bit of a factor too. I can count on one hand the number of times I’ve presented anything on a whiteboard at work, yet just about every company asks these questions during interviews. A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in. Whiteboard coding interviews are one thing that I have to go out of my way to practice for and get better at over time when interviewing (ie over the course of a few failed interviews). I don’t feel more skilled or smarter by the end of the set of interviews, but I inevitably do better at these kinds of problems. Should the interview be testing my competency at day-to-day work skills or how well I’ve practiced my interview skills, because whiteboard coding problems only achieve the latter.
    - lev99 8y ago
      > A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in. I do coding interviews in the following manner: I select an interesting problem from a book. I personally complete the problem, measuring what was challenging and the time it took for me to complete the problem. I check the textbook solution, making notes of how my solution differs from the textbook's. If I like the problem, and if it fits with the development role, I invite the candidate to bring a development laptop, I give them a hard time limit of twice the time it took me to complete it, and have them share their screen while they attempt to complete it. Afterwards we test their solution, I ask them some questions about it. I grade based on code taste, the number of hints they need, and their completion time. All candidates for a position are given the same question. Performance in coding interview is about two third's of the overall candidate evaluation. The ability to sit down and write good code in a time constraint manner is a very important part of being a developer.
timr 8y ago
It's bizarre to me that you think that whiteboard coding tests "communication", in any way. It's not like a presentation, or anything. It's one-sided combat where someone with a secret tries to get someone who doesn't know the secret to regurgitate the secret, on the spot, while pretending that s/he didn't memorize the secret in advance while cramming a great big "Cracking the Programmer Secret" book to prepare for the entire silly exercise in Kabuki theater. If you want to test communication skills amongst programmers, I dunno...ask them to write something in coherent English. Or here's a crazy thought: ask them to document some code. I guarantee that 80% of working "rockstar coders" will fail (but not before whining, crankily, about how unfair it is that you would actually make them do such a useless thing, since, y'know...never actually documents anything IRL, dude). Programmers like whiteboarding because it lets them believe that interviews can be reduced to purely objective functions, and because GooAmaSoftBook does it. They're too scared to deviate from the pack, lest people think they aren't as "elite" as everyone else.
- java-man 8y ago
  or do a code review
  - timr 8y ago
    Indeed. Or give a talk, or write a design doc, or...so many better options, all of which could be balanced out across a day of interviews. Think how much you might actually learn about a candidate if your interview process replaced a day of solid whiteboarding with a code review, some pair programming, a session of documenting someone else's code, behavioral interviews, etc. It's almost as if you'd be treating them like a...person!
- deleted 8y ago
  [deleted]
- remoteorbust 8y ago
  > It's bizarre to me that you think that whiteboard coding tests "communication", in any way. It's not like a presentation, or anything. I feel like we're probably at an impasse if I can't convince you that a whiteboard is a decent medium to communicate ideas around datastructures and algorithms, but I appreciate your point of view. I can only say my experience, which I hope you will take into account as one anecdote. I don't read books about "cracking the coding interview" or do leetcode or hackerrank. I left school 14 years ago or so my stash of cs trivia/secrets/gotcha isn't particularly full. I've done whiteboard interviews where I come up with at best a naive solution. And yet I've received offers for fairly senior engineering positions at Amazon and Twitter and (hopefully tomorrow) from Google. Most of the whiteboard interview isn't even around the code, although that's a small part. Most of it is analyzing the problem, discussing constraints, discussing tradeoffs, walking through data structure manipulations, drawing arrows and boxes, that kind of stuff. Some code, maybe 30% of the interview. I just keep having this experience where nobody wants to play the gotcha game, they want to know how well I can communicate while solving a problem and they think they get that information out of the interview (I agree with them). That experience makes it hard for me to understand a viewpoint that believes that whiteboard interviews are about memorizing secrets in advance.
KhanMahGretsch 8y ago
> What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? Perhaps it would be more effective to have the candidate whiteboard a concept that they are already familiar with, be it a high-level engineering principle or a system/solution they have built in the past. Attempting to solve a problem you have just been presented with AND communicating the solution effectively is a big ask.
- loxias 8y ago
  That's an awesome idea -- as someone who rabidly hates whiteboard interviews, to the extent that I'm looking at the responses in this article as a note of who to consider applying with next, I would love the challenge of "explain a complex concept you're already familiar with". I've never gotten that in an interview before.
- remoteorbust 8y ago
  That's an excellent idea. I'm in no way saying the existing method is perfect. Just that some of the things it tests around communication and being put on the spot and analyzing a problem in a way that is understandable to the rest of the room is actually a really good engineering skill. There can be other great ways to measure those skills. I know my opinion is unpopular, but I sometimes do think I've figured out something other people miss. I think when it comes to whiteboard inteviews, candidates are often playing the wrong game. They think it's about gotcha questions and they think they fail because they didn't leetcode hard enough. I don't think that's true, they are just trying to game the thing that's easy to measure. In my experience with the "terrible" FANG companies, it's not about gotcha questions. I get the offers even though I don't often find a non-naive solution. The people I'm in the room with really do want to see my thought process and they really do want me to communicate the tradeoffs with them. People don't fail the gotcha questions because they don't know trivia or because they forgot a detail from their CS classes. They fail the whiteboard interview because they see an unfamiliar question and say: "I don't know that trivia" instead of drawing out possible solutions and having a conversation with their interviewers.
  - 8y ago
gaius 8y ago
What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? This is incredibly common, and you tell the candidate in advance that they will be expected to give an n-minute presentation on a subject of their choosing (need not even be tech) so they can prepare. Tell me this: when did a mob last ambush you at your desk and demand that you invert a red-black tree on a whiteboard that they happen to have with them right now? I'm guessing that never happens where you work. If it does then fair enough :-)
spike021 8y ago
>I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low. I think it's safe to say that being put on the spot in front of people you don't know who are judging you is quite different from being put on the spot in a team meeting with someone from product who will watch your demo of a potential new project/idea/concept.
- 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.
meheleventyone 8y ago
I agree with the sentiment but find most of my whiteboard time concerned with a much higher level type of problem solving than writing lines of code or absolutely correct algorithms. I also mostly do it with colleagues I know on shared problems we are working cooperatively to solve. Where I’m using one with strangers I’m much more often working as an expert in an explanatory manner. It feels quite remote to my experience of solving an unknown problem in an interview situation.
techwraith 8y ago
VPE at Eaze here - Clear and respectful communication is one of the most important skills for an engineer to have. If you read the second half of my answer in the article I go into the communication side of things. In my experience there are better ways to evaluate a candidate's emotional intelligence and social skills than asking them to code in front of someone.
- oblio 8y ago
  I'd say you should stick to your guns - I like your approach. Interviews are inherently adversarial: "are you good enough for us to hire you?", "are you better than the other 5-10-1000 candidates". As a result there's a built-in bias which makes whiteboarding a bad fit. I've written code on white boards at work, and I've discussed about code on white board with colleagues or managers. It's not the same thing as during interviews. The schedule is never as tight, scrutiny is way laxer and the overall mood is completely different when I'm working with colleagues or even bosses. I kind of understand why the BigCo's do it (they need a super rigid filter since they have so many candidates), but in their case they could select for people with the best pink leotard on interview day and they'd still get decent programmers, because their companies are in such high demand and they generally already control their markets (software, natural monopolies, etc.) and can afford to pay a ton so the competition would be cutthroat anyway.
dave_sid 8y ago
Coding on a whiteboard while being questioned by two or more interviewers isn’t really a true representation of a work situation. It’s always more stressful and some people thrive on it, some people don’t. Im not sure what the better alternative is to demonstrate verba/technical communication skills however. The problem is, it’s hard to figure out if someone is a good fit with just a couple of hours of vigorous questioning. Maybe that’s the problem. I’d say I’ve worked with plenty of colleagues where it took me weeks or months to fully appreciate how extremely valuable they are to the team.
emmelaich 8y ago
Yes! What you're testing is the ability to discuss a problem with your peers. That is the critical thing. Do the whiteboard but don't make the coding the standard. Don't get too hung up on the details of the problem. Make the problem easy but fuzzily specified.
seanmcdirmid 8y ago
Then test that. Having someone code on a whiteboard, even if they are explaining what they are doing while they go along, is simply not the same thing as being good at using on the fly visual aides while communicating. In any case, that isn’t coding either.
- nerpderp83 8y ago
  You have 40 minutes to make a slide deck that explains bloomfilters and 5 minutes to present in front of the director of engineering.
  - seanmcdirmid 8y ago
    That is the same as saying who can code the fastest rather than who does the best job. But at the PhD level there will be a presentation given regardless.
xyzzy123 8y ago
Never seen anyone write code on a whiteboard at work. Do write lots of sequence diagrams, block diagrams, ui sketches, arch diagrams and very occasionally someone might draw a data structure.
- dsr_ 8y ago
  This. Plus network diagrams, message passing sequences, and first drafts of checklists.
achikin 8y ago
I communicate my ideas using a whiteboard too. But I never produce those ideas using a whiteboard in front of my coworkers under pressure of being fired.
- jaredklewis 8y ago
  Well this is hardly the fault of white board interviews. That’s just interviews. Any interview (regardless of the style) is going to be in front of “coworkers” and “under pressure of being fired.”
  - florabuzzword 8y ago
    My experience agrees with this. I am a different, significantly less comfortable person to be around when strangers are asking me so many questions about myself. I think it’s just about the worst way to get to know me. When I get hired this way, I always feel a little bit of guilt because I know they actually hired somebody else. What can be done? I’m not sure, but I can say one thing: my level of discomfort is multiplied by the number of strangers in the room. Does this ever get considered with interviews? I am far more comfortable coding in front of 1 or 2 people who each give me a little bit of background about their coding experience; just so I know. If they are experienced engineers, it’s probably not going to change what I say aloud, but it just makes me more comfortable. I guess more overlap of technologies in our background does help. It’s nice to not feel pressure of worrying if my solutions reflect general programming conventions enough to be language agnostic. I have never really used Java, for example.
  - thaumasiotes 8y ago
    The "produce the ideas during the interview" part is the fault of whiteboard interviews. There's nothing that says an interview should cover brand-new material as opposed to material the candidate is supposed to be familiar with. If communicating ideas is part of your job, I'd bet any amount that you decide what ideas you want to communicate well before you do the actual presentation (or other physical delivery of the ideas).
  - hfdgiutdryg 8y ago
baddox 8y ago
I don’t think there’s much criticism of those types of whiteboard interviews. I’ve had programmer interviews that involved sketching out a system architecture or database scheme on a whiteboard, which I think is perfectly reasonable.
arcticbull 8y ago
How about testing architecture (and implicitly communication) in front of a whiteboard and programming behind a keyboard?
Yhippa 8y ago
It's one thing to do it with colleagues for whom you have rapport and the risk of saying something wrong is low. It's a different thing when doing it around total strangers and a new job is on the line.
hueving 8y ago
Ugh, communicating with a whiteboard has no overlap with developing a solution to a completely unexpected quiz (if you didn't cheat) on a whiteboard in front of someone scrutinizing your every move with your future career on the line. Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not. If you defend whiteboard leetcode using this excuse you are deluding yourself and you are part of the problem. The only thing the modern FANG interview hires for is people that can solve algorithms problems in a silo under pressure. No checks for software engineering skills, collaboration skills, testing skills, reviewing skills, and on and on... The whiteboard interview is why so many engineers unexpectedly suck.
- dasil003 8y ago
  Agree with most of what you said except the conclusion. The reason many engineers unexpectedly suck is because it’s a high paying job where performance is difficult to measure let alone predict. White boarding interviews are a symptom of the problem, not the cause of it.
- hvidgaard 8y ago
  > Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not. They you are asking the wrong questions. I use whiteboard for developers, and for junior developers I give them a simple task such as reverse an array, turn a string into a palindrome (and explain what it is if they don't know). If they want to be a developer they must be able to solve those simple tasks. I don't really care how, as long as they think loud. Then I use it as a starting point for enhancement discussions, perhaps stack/heap questions, recursion, assignments ect. During all this I coach them, teach unknown concepts in simple terms - this is what they can expect when they ask their mentor a question so in that sense they get a feel for us too. Some argue that it's still not good, and that we're filtering out people that work best alone. That is true, but that is by design. We work as a team, having 10 individual developers not working together unless forced is an architectural nightmare.
  - 8y ago
itronitron 8y ago
>> What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? In that case I would recommend reading the candidate's resume beforehand, look for prior experience publishing, presenting, or teaching and ask them about it.
screye 8y ago
I think now a days, selection through the whiteboard process simply comes first to how much you grind leet code and the like. Ironically this leads to min- maxxers who ignore a good chunk of their courses simply to master leetcode. My smartest peers are ones who work on interesting projects and research, thus never finding time to grind interview questions. Then there are also companies that expect your white board code to compile and have perfect syntax, which imo is very unreasonable.
jkoudys 8y ago
I agree, and as an employer I find a happy medium is to test on a whiteboard, but be completely okay writing filler, a comment saying "code for this goes here", etc. So long as they're building the correct general approach, that's all I need to see. Whiteboard interviews where the interviewer says "it's actually `.toLowerCase()`, not `.lowerCase()`, you fool!", or "oops! You forgot to `position: relative;` the containing element that you `position: absolute;`d below!". you're not testing anything useful. Maybe if we were still coding everything on punchcards and using massive user manuals, but docking applicants for things their editor would highlight or one ctrl-r on the page would find is ridiculous.

java-man 8y ago

even then, this is not what's being tested with the whiteboard. thinking and presenting are two separate skills, and, in my opinion, can rarely be executed at the same time.

vymague 8y ago
So if you're looking for someone who can execute both at the same time, whiteboard coding is ok?
- swsieber 8y ago
  If your looking for someone who can think, code and present at the same time, yes.
deleted 8y ago
[deleted]

jdc 8y ago

The point is that the interview style in question overemphasizes on-the-spot responses. How is prowess in a game of "gotcha" an important indicator of engineering skill?

munchbunny 8y ago
I tend to agree with (what I think is) the sentiment of some of the respondents in the article: if your whiteboard interview is a game of gotcha, then the problem is your interviewer, not the whiteboard. I think the complaint that programmers pretty much never have to think about code under pressure is a fair criticism. The whiteboard really puts you on the spot. But if it's your company and your hiring managers are playing a game of gotcha on the whiteboard, you need better interviewers.
- java-man 8y ago
  in a sense, I agree. this is a signal to the candidate that the interviewers do not fully understand what they are measuring. which also means the team might consist of people selected by using this metric. this is a good signal ;-)
- ilikehurdles 8y ago
  State dependent learning is a bit of a factor too. I can count on one hand the number of times I’ve presented anything on a whiteboard at work, yet just about every company asks these questions during interviews. A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in. Whiteboard coding interviews are one thing that I have to go out of my way to practice for and get better at over time when interviewing (ie over the course of a few failed interviews). I don’t feel more skilled or smarter by the end of the set of interviews, but I inevitably do better at these kinds of problems. Should the interview be testing my competency at day-to-day work skills or how well I’ve practiced my interview skills, because whiteboard coding problems only achieve the latter.
  - lev99 8y ago
    > A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in. I do coding interviews in the following manner: I select an interesting problem from a book. I personally complete the problem, measuring what was challenging and the time it took for me to complete the problem. I check the textbook solution, making notes of how my solution differs from the textbook's. If I like the problem, and if it fits with the development role, I invite the candidate to bring a development laptop, I give them a hard time limit of twice the time it took me to complete it, and have them share their screen while they attempt to complete it. Afterwards we test their solution, I ask them some questions about it. I grade based on code taste, the number of hints they need, and their completion time. All candidates for a position are given the same question. Performance in coding interview is about two third's of the overall candidate evaluation. The ability to sit down and write good code in a time constraint manner is a very important part of being a developer.

timr 8y ago

It's bizarre to me that you think that whiteboard coding tests "communication", in any way. It's not like a presentation, or anything. It's one-sided combat where someone with a secret tries to get someone who doesn't know the secret to regurgitate the secret, on the spot, while pretending that s/he didn't memorize the secret in advance while cramming a great big "Cracking the Programmer Secret" book to prepare for the entire silly exercise in Kabuki theater. If you want to test communication skills amongst programmers, I dunno...ask them to write something in coherent English. Or here's a crazy thought: ask them to document some code. I guarantee that 80% of working "rockstar coders" will fail (but not before whining, crankily, about how unfair it is that you would actually make them do such a useless thing, since, y'know...never actually documents anything IRL, dude). Programmers like whiteboarding because it lets them believe that interviews can be reduced to purely objective functions, and because GooAmaSoftBook does it. They're too scared to deviate from the pack, lest people think they aren't as "elite" as everyone else.

java-man 8y ago
or do a code review
- timr 8y ago
  Indeed. Or give a talk, or write a design doc, or...so many better options, all of which could be balanced out across a day of interviews. Think how much you might actually learn about a candidate if your interview process replaced a day of solid whiteboarding with a code review, some pair programming, a session of documenting someone else's code, behavioral interviews, etc. It's almost as if you'd be treating them like a...person!
deleted 8y ago
[deleted]
remoteorbust 8y ago
> It's bizarre to me that you think that whiteboard coding tests "communication", in any way. It's not like a presentation, or anything. I feel like we're probably at an impasse if I can't convince you that a whiteboard is a decent medium to communicate ideas around datastructures and algorithms, but I appreciate your point of view. I can only say my experience, which I hope you will take into account as one anecdote. I don't read books about "cracking the coding interview" or do leetcode or hackerrank. I left school 14 years ago or so my stash of cs trivia/secrets/gotcha isn't particularly full. I've done whiteboard interviews where I come up with at best a naive solution. And yet I've received offers for fairly senior engineering positions at Amazon and Twitter and (hopefully tomorrow) from Google. Most of the whiteboard interview isn't even around the code, although that's a small part. Most of it is analyzing the problem, discussing constraints, discussing tradeoffs, walking through data structure manipulations, drawing arrows and boxes, that kind of stuff. Some code, maybe 30% of the interview. I just keep having this experience where nobody wants to play the gotcha game, they want to know how well I can communicate while solving a problem and they think they get that information out of the interview (I agree with them). That experience makes it hard for me to understand a viewpoint that believes that whiteboard interviews are about memorizing secrets in advance.

KhanMahGretsch 8y ago

> What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? Perhaps it would be more effective to have the candidate whiteboard a concept that they are already familiar with, be it a high-level engineering principle or a system/solution they have built in the past. Attempting to solve a problem you have just been presented with AND communicating the solution effectively is a big ask.

loxias 8y ago
That's an awesome idea -- as someone who rabidly hates whiteboard interviews, to the extent that I'm looking at the responses in this article as a note of who to consider applying with next, I would love the challenge of "explain a complex concept you're already familiar with". I've never gotten that in an interview before.
remoteorbust 8y ago
That's an excellent idea. I'm in no way saying the existing method is perfect. Just that some of the things it tests around communication and being put on the spot and analyzing a problem in a way that is understandable to the rest of the room is actually a really good engineering skill. There can be other great ways to measure those skills. I know my opinion is unpopular, but I sometimes do think I've figured out something other people miss. I think when it comes to whiteboard inteviews, candidates are often playing the wrong game. They think it's about gotcha questions and they think they fail because they didn't leetcode hard enough. I don't think that's true, they are just trying to game the thing that's easy to measure. In my experience with the "terrible" FANG companies, it's not about gotcha questions. I get the offers even though I don't often find a non-naive solution. The people I'm in the room with really do want to see my thought process and they really do want me to communicate the tradeoffs with them. People don't fail the gotcha questions because they don't know trivia or because they forgot a detail from their CS classes. They fail the whiteboard interview because they see an unfamiliar question and say: "I don't know that trivia" instead of drawing out possible solutions and having a conversation with their interviewers.
- 8y ago

gaius 8y ago

What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? This is incredibly common, and you tell the candidate in advance that they will be expected to give an n-minute presentation on a subject of their choosing (need not even be tech) so they can prepare. Tell me this: when did a mob last ambush you at your desk and demand that you invert a red-black tree on a whiteboard that they happen to have with them right now? I'm guessing that never happens where you work. If it does then fair enough :-)

spike021 8y ago

>I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low. I think it's safe to say that being put on the spot in front of people you don't know who are judging you is quite different from being put on the spot in a team meeting with someone from product who will watch your demo of a potential new project/idea/concept.

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.

meheleventyone 8y ago

I agree with the sentiment but find most of my whiteboard time concerned with a much higher level type of problem solving than writing lines of code or absolutely correct algorithms. I also mostly do it with colleagues I know on shared problems we are working cooperatively to solve. Where I’m using one with strangers I’m much more often working as an expert in an explanatory manner. It feels quite remote to my experience of solving an unknown problem in an interview situation.

techwraith 8y ago

VPE at Eaze here - Clear and respectful communication is one of the most important skills for an engineer to have. If you read the second half of my answer in the article I go into the communication side of things. In my experience there are better ways to evaluate a candidate's emotional intelligence and social skills than asking them to code in front of someone.

oblio 8y ago
I'd say you should stick to your guns - I like your approach. Interviews are inherently adversarial: "are you good enough for us to hire you?", "are you better than the other 5-10-1000 candidates". As a result there's a built-in bias which makes whiteboarding a bad fit. I've written code on white boards at work, and I've discussed about code on white board with colleagues or managers. It's not the same thing as during interviews. The schedule is never as tight, scrutiny is way laxer and the overall mood is completely different when I'm working with colleagues or even bosses. I kind of understand why the BigCo's do it (they need a super rigid filter since they have so many candidates), but in their case they could select for people with the best pink leotard on interview day and they'd still get decent programmers, because their companies are in such high demand and they generally already control their markets (software, natural monopolies, etc.) and can afford to pay a ton so the competition would be cutthroat anyway.

dave_sid 8y ago

Coding on a whiteboard while being questioned by two or more interviewers isn’t really a true representation of a work situation. It’s always more stressful and some people thrive on it, some people don’t. Im not sure what the better alternative is to demonstrate verba/technical communication skills however. The problem is, it’s hard to figure out if someone is a good fit with just a couple of hours of vigorous questioning. Maybe that’s the problem. I’d say I’ve worked with plenty of colleagues where it took me weeks or months to fully appreciate how extremely valuable they are to the team.

emmelaich 8y ago

Yes! What you're testing is the ability to discuss a problem with your peers. That is the critical thing. Do the whiteboard but don't make the coding the standard. Don't get too hung up on the details of the problem. Make the problem easy but fuzzily specified.

seanmcdirmid 8y ago

Then test that. Having someone code on a whiteboard, even if they are explaining what they are doing while they go along, is simply not the same thing as being good at using on the fly visual aides while communicating. In any case, that isn’t coding either.

nerpderp83 8y ago
You have 40 minutes to make a slide deck that explains bloomfilters and 5 minutes to present in front of the director of engineering.
- seanmcdirmid 8y ago
  That is the same as saying who can code the fastest rather than who does the best job. But at the PhD level there will be a presentation given regardless.

xyzzy123 8y ago

Never seen anyone write code on a whiteboard at work. Do write lots of sequence diagrams, block diagrams, ui sketches, arch diagrams and very occasionally someone might draw a data structure.

dsr_ 8y ago
This. Plus network diagrams, message passing sequences, and first drafts of checklists.

achikin 8y ago

I communicate my ideas using a whiteboard too. But I never produce those ideas using a whiteboard in front of my coworkers under pressure of being fired.

jaredklewis 8y ago
Well this is hardly the fault of white board interviews. That’s just interviews. Any interview (regardless of the style) is going to be in front of “coworkers” and “under pressure of being fired.”
- florabuzzword 8y ago
  My experience agrees with this. I am a different, significantly less comfortable person to be around when strangers are asking me so many questions about myself. I think it’s just about the worst way to get to know me. When I get hired this way, I always feel a little bit of guilt because I know they actually hired somebody else. What can be done? I’m not sure, but I can say one thing: my level of discomfort is multiplied by the number of strangers in the room. Does this ever get considered with interviews? I am far more comfortable coding in front of 1 or 2 people who each give me a little bit of background about their coding experience; just so I know. If they are experienced engineers, it’s probably not going to change what I say aloud, but it just makes me more comfortable. I guess more overlap of technologies in our background does help. It’s nice to not feel pressure of worrying if my solutions reflect general programming conventions enough to be language agnostic. I have never really used Java, for example.
- thaumasiotes 8y ago
  The "produce the ideas during the interview" part is the fault of whiteboard interviews. There's nothing that says an interview should cover brand-new material as opposed to material the candidate is supposed to be familiar with. If communicating ideas is part of your job, I'd bet any amount that you decide what ideas you want to communicate well before you do the actual presentation (or other physical delivery of the ideas).
- hfdgiutdryg 8y ago

baddox 8y ago

I don’t think there’s much criticism of those types of whiteboard interviews. I’ve had programmer interviews that involved sketching out a system architecture or database scheme on a whiteboard, which I think is perfectly reasonable.

arcticbull 8y ago

How about testing architecture (and implicitly communication) in front of a whiteboard and programming behind a keyboard?

Yhippa 8y ago

It's one thing to do it with colleagues for whom you have rapport and the risk of saying something wrong is low. It's a different thing when doing it around total strangers and a new job is on the line.

hueving 8y ago

Ugh, communicating with a whiteboard has no overlap with developing a solution to a completely unexpected quiz (if you didn't cheat) on a whiteboard in front of someone scrutinizing your every move with your future career on the line. Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not. If you defend whiteboard leetcode using this excuse you are deluding yourself and you are part of the problem. The only thing the modern FANG interview hires for is people that can solve algorithms problems in a silo under pressure. No checks for software engineering skills, collaboration skills, testing skills, reviewing skills, and on and on... The whiteboard interview is why so many engineers unexpectedly suck.

dasil003 8y ago
Agree with most of what you said except the conclusion. The reason many engineers unexpectedly suck is because it’s a high paying job where performance is difficult to measure let alone predict. White boarding interviews are a symptom of the problem, not the cause of it.
hvidgaard 8y ago
> Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not. They you are asking the wrong questions. I use whiteboard for developers, and for junior developers I give them a simple task such as reverse an array, turn a string into a palindrome (and explain what it is if they don't know). If they want to be a developer they must be able to solve those simple tasks. I don't really care how, as long as they think loud. Then I use it as a starting point for enhancement discussions, perhaps stack/heap questions, recursion, assignments ect. During all this I coach them, teach unknown concepts in simple terms - this is what they can expect when they ask their mentor a question so in that sense they get a feel for us too. Some argue that it's still not good, and that we're filtering out people that work best alone. That is true, but that is by design. We work as a team, having 10 individual developers not working together unless forced is an architectural nightmare.
- 8y ago

itronitron 8y ago

>> What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? In that case I would recommend reading the candidate's resume beforehand, look for prior experience publishing, presenting, or teaching and ask them about it.

screye 8y ago

I think now a days, selection through the whiteboard process simply comes first to how much you grind leet code and the like. Ironically this leads to min- maxxers who ignore a good chunk of their courses simply to master leetcode. My smartest peers are ones who work on interesting projects and research, thus never finding time to grind interview questions. Then there are also companies that expect your white board code to compile and have perfect syntax, which imo is very unreasonable.

jkoudys 8y ago

I agree, and as an employer I find a happy medium is to test on a whiteboard, but be completely okay writing filler, a comment saying "code for this goes here", etc. So long as they're building the correct general approach, that's all I need to see. Whiteboard interviews where the interviewer says "it's actually `.toLowerCase()`, not `.lowerCase()`, you fool!", or "oops! You forgot to `position: relative;` the containing element that you `position: absolute;`d below!". you're not testing anything useful. Maybe if we were still coding everything on punchcards and using massive user manuals, but docking applicants for things their editor would highlight or one ctrl-r on the page would find is ridiculous.