Engineering whiteboard interviews: yay or nay? • Hacker News Board

Re: Engineering whiteboard interviews: yay or nay?

#91

Post by stevenwoo » Thu, Aug 09, 2018, 8:37 PM UTC

miah_ wrote: post #37

h4b4n3r0 wrote: post #14

Nay, unless the candidate wants the whiteboard. Even Google doesn't mandate whiteboard anymore: you can write your code on the provided Chromebook. Some people choose whiteboard, though, for reasons unknown. I think whiteboard (or a sheet of paper) is reasonable for what it gets used for IRL: for sketching out what you're going to do, by drawing or writing very high level description, but it sucks for everything else…

I did a interview with Google last summer. They didn't use a whiteboard, but instead had me code in a shared GoogleDoc. Pretty similar issue, limited time, somebody staring over your shoulder, not your usual development environment. Even more frustrating when you _know_ they have a web-based IDE for internal software development but make you write code in a GoogleDoc.

I did one about ten years ago, two of the guys asked me to do the program on legal pads, two on a whiteboard, it was kind of funny because the Google HR person gave out a pdf explaining they were going to use a whiteboard and to practice on a whiteboard before coming on site.

Re: Engineering whiteboard interviews: yay or nay?

#92

Post by KhanMahGretsch » Thu, Aug 09, 2018, 8:38 PM UTC

haeffin wrote: post #35

denzil_correa wrote: post #27

In general, an interview is to understand what a candidate brings to the table. Therefore, one of the best ways to assess "glass half full" is to talk about their past work. The interviewer is a subject matter expert who can definitely ask pertinent questions about the candidate's work. In many cases, more so for scientific positions - the candidate's work is publicly available. Currently, many interviewers go for -…

Unfortunately, some companies' HR departments actively encourage "trivia questions", because they ask interviewers to ask every candidate the same questions so that a "fair" comparison between candidates.

I think you've touched on a crucial point here about making the comparison "fair". In my view, I find the "trivia questions" approach to be an abdication of responsibility for the difficult, nebulous task of assessing a candidate's abilities. It gives you an objective measure by which to compare candidates... even though the measure itself is usually arbitrary and irrelevant.

Re: Engineering whiteboard interviews: yay or nay?

#93

Post by java-man » Thu, Aug 09, 2018, 8:38 PM UTC

UncleMeat wrote: post #78

java-man wrote: post #59

Earlier quoted context omitted.

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.

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.…

so let's discuss the edge cases. let's operate with abstract concepts rather than actually write code.

Re: Engineering whiteboard interviews: yay or nay?

#94

Post by meheleventyone » Thu, Aug 09, 2018, 8:42 PM UTC

remoteorbust wrote: post #45

bradenb wrote: post #2

VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do? This comes close, but I think the re…

> 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…

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.

Re: Engineering whiteboard interviews: yay or nay?

#95

Post by [deleted] » Thu, Aug 09, 2018, 8:42 PM UTC

timr wrote: post #62

remoteorbust wrote: post #45

Earlier quoted context omitted.

> 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…

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 t…

[deleted]

Re: Engineering whiteboard interviews: yay or nay?

#96

Post by h4b4n3r0 » Thu, Aug 09, 2018, 8:43 PM UTC

miah_ wrote: post #37

h4b4n3r0 wrote: post #14

Nay, unless the candidate wants the whiteboard. Even Google doesn't mandate whiteboard anymore: you can write your code on the provided Chromebook. Some people choose whiteboard, though, for reasons unknown. I think whiteboard (or a sheet of paper) is reasonable for what it gets used for IRL: for sketching out what you're going to do, by drawing or writing very high level description, but it sucks for everything else…

I did a interview with Google last summer. They didn't use a whiteboard, but instead had me code in a shared GoogleDoc. Pretty similar issue, limited time, somebody staring over your shoulder, not your usual development environment. Even more frustrating when you _know_ they have a web-based IDE for internal software development but make you write code in a GoogleDoc.

With doc you don’t have to stare over the candidate’s shoulder. The interviewer can just share the doc with him/herself and watch as you type. That’s what I used to do. The main goal is actually to make sure the candidate stays on the right track. Some folks are prone to veering way out into the woods otherwise. Unsupervised, they would just run out of time.

Re: Engineering whiteboard interviews: yay or nay?

#97

Post by techwraith » Thu, Aug 09, 2018, 8:43 PM UTC

bradenb wrote: post #2

VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do? This comes close, but I think the re…

VPE at Eaze here (the original author of the quote above) -

You're 100% correct. We give our candidates the choice between working through a problem at the office (on the spot as you say) or doing a take home project asynchronously. Not everyone has the time to do homework, but not everyone wants to do an in person coding interview either. We try to stay flexible.

Re: Engineering whiteboard interviews: yay or nay?

#98

Post by java-man » Thu, Aug 09, 2018, 8:43 PM UTC

munchbunny wrote: post #89

jdc wrote: post #60

Earlier quoted context omitted.

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?

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…

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 ;-)

Re: Engineering whiteboard interviews: yay or nay?

#99

Post by LaserToy » Thu, Aug 09, 2018, 8:43 PM UTC

Principal Engineer from huge gaming company here.

White board coding interview are testing only one thing: how well candidate is prepared for it. And here what is wrong with it: The assumption that candidate should spend his/her valuable time preparing for someone's assessment is arrogant. I do understand why Google and Facebook do it (the do other arrogant things), they assume you want to work for them so much you will study to make the cut. So, they track bunch of metrics, which makes THEIR life easier. They have baselines, calibrations, and other things you never have in the real life. Hilarious part is that they are both risk averse (better to not hire a good candidate than hire a bad one) and using brood-force approach (they will interview you endless number of time).

And if you are not prepared - you will most probably fail, unless you are really good at it or lucky. So, why should I prepare for Google's or someone's else interview? I have a interesting and very busy job, I just don't have time for this. I have commitments to my team to work on real products, not on fake problems from Cracking Google Coding Interview.

Just think how absurd it is?

So, starting from 6 month ago I: 1) Tell recruiters upfront I will not be spending a minute preparing for their interview process 2) I decline coding on the whiteboard. High level designs are fine, writing code - no, no exceptions 3) And the most important, I stopped asking candidates to code on the white board.

The most important skill of the software engineer is (IMO): ability to keep complex problems in context for long time (not 5 boxes and months), ability to manipulate them and ability to convince others that you idea is worth pursuing.

Re: Engineering whiteboard interviews: yay or nay?

#100

Post by remoteorbust » Thu, Aug 09, 2018, 8:44 PM UTC

KhanMahGretsch wrote: post #70

remoteorbust wrote: post #45

Earlier quoted context omitted.

> 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…

> 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 communica…

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.