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

41–50 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#41

Post by sbov »

ubernostrum wrote: post #30
iamNumber4 wrote: post #24

Earlier quoted context omitted.

Coding challenges either take home or live session. Most whiteboard questions are always some esoteric algorithm any engineer worth their salt would in real life would look up before ever consider using to verify their own understanding before using it. Putting someone on the spot saying whiteboard x is not ok. However if the test is to see if they can take part in a meeting, then by all means do a white board, but a…

It's not just that real working engineers would go look it up. It's that the culture around these "prove you can code" problems got into an arms race, where companies kept trying to come up with ever more difficult problems and stringent requirements on solutions. It finally reached the point where, at some companies which use them, the bar for "can you code at all" is actually "given a problem you've never seen befo…

Yes, my favorite was a while back, someone's list of algorithmic interview questions got posted on here, and a couple of his answers were wrong! And he STILL insisted they were good interview questions!

Our field is full of some of the smartest morons on the planet.

Re: Engineering whiteboard interviews: yay or nay?

#42

Post by lfowles »

ubernostrum wrote: post #26
pavel_lishin wrote: post #3

Earlier quoted context omitted.

Minor kvetch: quoting the way you did it makes long lines very difficult to read. I usually quote like this: > I am a quote This makes the quotation doubly-distinct, and still readable on mobile devices. === To the actual point I wanted to make: plenty of engineers at companies code on a whiteboard. They schedule a meeting, grab a room, and talk things out, while making notes, diagrams and sometimes even actually wri…

"Whiteboard interview" typically does not mean "sketch a general design of a system", or the other things whiteboards get actually used for on the job. It means "here's an algorithm challenge, solve it by writing the code on the whiteboard, and we'll flunk you if you make any mistakes". Not always a whiteboard, either; one of the best engineers I ever knew flunked a Google interview because of a situation where he ha…

Oof, I've had that experience during a technical phone screen with a different "hires only the best" company. I was asked to write (over the phone) a trivial statistical algorithm and started to describe the algorithm: "Function F returns a double and has two parameters, pointer to the start of the double array P and integer N for length of array." Apparently on the other end of the line was a human compiler that kept rejecting my input and preferred "double F open parens double star P comma int n close parens"!

Re: Engineering whiteboard interviews: yay or nay?

#43

Post by curtis »

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 are not FizzBuzz. I've used the Fisher-Yates shuffle algorithm and more recently Selection Sort. I should stress in both of these cases that I carefully explained the algorithm before asking the interviewee to code it up. Even though these algorithms are quite simple, I do not expect the interviewee to have memorized them.

I do expect someone who is a professional software engineer to understand the algorithms after a decent explanation and then write code which will implement them.

I also don't necessarily expect the interviewee to get the code exactly right. I just expect them to demonstrate that they could write correct code given enough time and access to an actual computer to test the code on.

Re: Engineering whiteboard interviews: yay or nay?

#44

Post by pavel_lishin »

stlHusker wrote: post #31
recursive wrote: post #7

Earlier quoted context omitted.

Interviews are necessarily more stressful than typical work. That's not just a property of whiteboard coding.

"Interviews are necessarily more stressful than typical work. That's not just a property of whiteboard coding." My sister, a pediatric ER nurse would disagree with you. The interviews are largely behavioral and are a breeze. No dummy is wheeled in with head trauma, random "new" diseases aren't invented and asked to be treated, etc. The simple fact of the matter is if hospitals hired in the same way, they would have n…

I would argue that a piece of paper showing that someone attended school and graduated and is licensed to be an ER nurse carries much more weight than a piece of paper showing that I'm allegedly qualified to be a software engineer.

I know it's totally anecdotal, but we've all heard horror stories about candidates who couldn't write a for loop; some of us have witnessed these things first hand. And yes, phone screens should be filtering out those sorts of candidates long before they start sweating with a dry-erase marker in their hand, but, well.

How likely is an applicant for a nursing job to flat out not know how to stitch up a wound, or to take a patient's pulse and temperature?

Re: Engineering whiteboard interviews: yay or nay?

#45

Post by remoteorbust »

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

Re: Engineering whiteboard interviews: yay or nay?

#46

Post by BinaryIdiot »

pavel_lishin wrote: post #3
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…

Minor kvetch: quoting the way you did it makes long lines very difficult to read. I usually quote like this: > I am a quote This makes the quotation doubly-distinct, and still readable on mobile devices. === To the actual point I wanted to make: plenty of engineers at companies code on a whiteboard. They schedule a meeting, grab a room, and talk things out, while making notes, diagrams and sometimes even actually wri…

I've worked at quite a lot of companies. Many of us will, occasionally, grab a room / whiteboard to go over something but 99% of the time it's a sort of flow or UX type thing.

I've _never_ seen someone, or have asked to participate in, some sort of whiteboard coding thing. Even with pseudo code. That just doesn't seem helpful to me, at all.

Re: Engineering whiteboard interviews: yay or nay?

#48

Post by ngngngng »

My most recent interview involved a coding assignment, which I topically don't do, but this one was a very interesting challenge that would make a good blog post afterwards so I did it. What was surprising is the interview not only included going over my code from the assignment, but also whiteboard problems about recursion. I've still never used recursion in my day job. Can interviewers really not gauge technical ability from my GitHub as well as chatting about problems and solutions?

Re: Engineering whiteboard interviews: yay or nay?

#49

Post by BinaryIdiot »

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

Re: Engineering whiteboard interviews: yay or nay?

#50

Post by jonathankoren »

romaniv wrote: post #17
devy wrote: post #9

Serious question, if whiteboard interview aren't the best or helpful at all, what are the successful/useful alternatives for engineering interviews?

Letting candidates to do actual coding on a computer.

Yeah, but that's also stupid. All to often it comes down to "Make standup a completly working client server system for this arbitrary problem from scratch in 30 minutes, starting... NOW!"

You end up spending all your time dicking around with missed semicolons and looking up library routines and shit like that. Sure, it's all stuff you have to do as part of a job, but it's also all trivial stuff.

The last time I had to do this, I spent time googling how to open up a port in python, and then read from stdin. It's just a waste of time.

All this does is test the wrong things.

Post reply on HN