Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering whiteboard interviews: yay or nay?

keyvalues.com

Post reply on HN
Print view View original

71–80 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#71

Post by curtis »

BinaryIdiot wrote: post #49
curtis wrote: post #43

Many people believe that it is completely unreasonable to ask an interviewee to write code on a whiteboard at all. I disagree with such an absolute position. I do think it can be a reasonable thing to do, but only if you are asking the interviewee to code something really simple. When I say simple , I mean really simple, like FizzBuzz simple. There are interesting questions you can ask that are really simple which ar…

If you're looking for them to do something _really simple_, like FizzBuzz, then you're doing it wrong already. This is something that could have taken place over a technical phone screening. Once they hit the on site interview it should be more about how they can work together with a team, how they would design systems, what they would do if they needed help, etc. Coding up FizzBuzz on-site is a waste of everyone's t…

We're a small startup, and we don't have a really structured process. Also I have been the only person asking a detailed coding question (in consultation with my boss). Everybody else on the team has been responsible for those other questions.

I should also add that I personally prefer to do coding questions in person on a whiteboard, rather than doing them during a phone screen with some sort of collaboration software.

My technique of explaining the algorithm before asking the interviewee to implement it works way better with both people in front of a whiteboard.

I'm not saying everybody should do it this way. I'm just saying that this is my current approach and it seems like it's working OK.

Re: Engineering whiteboard interviews: yay or nay?

#72

Post by theptip »

The term "whiteboard interview" seems to mostly refer to "solving algorithmic/coding/puzzle problems on a whiteboard", which I agree is almost always a waste of time for a software engineering position.

As the article mentions though, the term is a bit vague and is overly broad; for example if you're doing a system design question, I'd argue that the whiteboard is the best choice for an interview, since that's how you're most likely to collaboratively sketch the design of a system in the real world.

I think the problem can be restated at a more general level; does the interview test the sort of skills that the job requires? Most people here are correctly pointing out that the skill/knowledge required to write out pseudocode for quicksort is almost entirely uncorrelated to the skills involved in most software jobs.

Re: Engineering whiteboard interviews: yay or nay?

#73

Post by ltdanimal »

BinaryIdiot wrote: post #49
curtis wrote: post #43

Many people believe that it is completely unreasonable to ask an interviewee to write code on a whiteboard at all. I disagree with such an absolute position. I do think it can be a reasonable thing to do, but only if you are asking the interviewee to code something really simple. When I say simple , I mean really simple, like FizzBuzz simple. There are interesting questions you can ask that are really simple which ar…

If you're looking for them to do something _really simple_, like FizzBuzz, then you're doing it wrong already. This is something that could have taken place over a technical phone screening. Once they hit the on site interview it should be more about how they can work together with a team, how they would design systems, what they would do if they needed help, etc. Coding up FizzBuzz on-site is a waste of everyone's t…

How exactly could you evaluate FizzBuzz over the phone? Its designed as a weed out question early on, if they can't do that (and yes some have failed) then it makes a decision pretty easy

Re: Engineering whiteboard interviews: yay or nay?

#74

Post by pavel_lishin »

lfowles wrote: post #61
scarejunba wrote: post #56

Earlier quoted context omitted.

This is hilarious! Such a strong indicator that you, as a candidate, should reject the employer.

Yes, it was the final straw and led to me rejecting that industry as a whole :)

What are you doing now?

Re: Engineering whiteboard interviews: yay or nay?

#75

Post by vymague »

java-man wrote: post #51
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…

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.

So if you're looking for someone who can execute both at the same time, whiteboard coding is ok?

Re: Engineering whiteboard interviews: yay or nay?

#76

Post by lfowles »

pavel_lishin wrote: post #74
lfowles wrote: post #61

Earlier quoted context omitted.

Yes, it was the final straw and led to me rejecting that industry as a whole :)

What are you doing now?

Makin' games, burnin' savings.

https://www.youtube.com/watch?v=V7MXfg2wt28&list=PLqJcvcLs4C...

Re: Engineering whiteboard interviews: yay or nay?

#78

Post by UncleMeat »

java-man wrote: post #59
romille wrote: post #39

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…

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. That isn't a property of whiteboard interviews.

Re: Engineering whiteboard interviews: yay or nay?

#79

Post by swsieber »

vymague wrote: post #75
java-man wrote: post #51

Earlier quoted context omitted.

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.

So if you're looking for someone who can execute both at the same time, whiteboard coding is ok?

If your looking for someone who can think, code and present at the same time, yes.

Re: Engineering whiteboard interviews: yay or nay?

#80

Post by sgslo »

romille wrote: post #39

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…

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?

Post reply on HN