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

21–30 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#21

Post by KallDrexx »

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?

I haven't had the opportunity yet but I really want to take a piece of code from our system, de-optimize it a bit and add some bugs, then give users a unit test around it.

Most of what we do as engineers is trying to read code to figure out what it's doing, how to fix it and how to enhance it. Going through real code with a candidate and assessing their ability to understand brand new code (and what questions they ask) seems like it would give good insight to how they would perform on the job.

Re: Engineering whiteboard interviews: yay or nay?

#22

Post by a-dub »

Whiteboard interviews would be fine if they weren't taken so damn literally. Writing code on the board is dumb.

Spitballing solutions to a problem collaboratively and with access to reference resources (a nice little programmer's bookshelf in the room) followed by actually coding a little bit up seems that it would be way less stressful and way more likely to give you a sense as to what someone is capable of and what they're like to work with.

Re: Engineering whiteboard interviews: yay or nay?

#23

Post by romaniv »

teachrdan wrote: post #5
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…

There's some logic to that. It's the one of the same reasons we have high stakes exams in school: to show what the individual can do under pressure. In an interview setting you can't simulate what it's like to be at the end of a high-intensity sprint, but you can ask the candidate to answer a tough question on a whiteboard and (ideally) get a notion of how they work when the going gets tough.

The pressure of a whiteboard interview has nothing in common with the pressure of a short deadline. It's like testing people for Tour de France by putting them on a unicycle.

Re: Engineering whiteboard interviews: yay or nay?

#24

Post by iamNumber4 »

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?

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 ask them draw a workflow diagram or some other 40,000 foot type of diagram. Do not ask them to put code on a whiteboard.

Re: Engineering whiteboard interviews: yay or nay?

#25

Post by dylanrw »

jriot wrote: post #16
teachrdan wrote: post #5

Earlier quoted context omitted.

There's some logic to that. It's the one of the same reasons we have high stakes exams in school: to show what the individual can do under pressure. In an interview setting you can't simulate what it's like to be at the end of a high-intensity sprint, but you can ask the candidate to answer a tough question on a whiteboard and (ideally) get a notion of how they work when the going gets tough.

As a former air traffic controller and now data scientist, nothing in this career field is ever done under any real pressure.

But what about that one time on Swordfish!? /s

Re: Engineering whiteboard interviews: yay or nay?

#26

Post by ubernostrum »

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…

"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 had to write a bash script and read it over the phone to the interviewer, who apparently didn't transcribe it correctly on the other end. But "they only hire the best", you know, and their practices are rock-solid and proven.

Re: Engineering whiteboard interviews: yay or nay?

#27

Post by denzil_correa »

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 - as I like to call it -"trivia questions". Personally, it just doesn't seem appropriate because "Everything may be obvious, once you know the answer". In some such interviews, I've asked my own set of trivia questions to the interviewers. The interviewers weren't pleased as they couldn't answer some questions for which I knew the answers beforehand.

Re: Engineering whiteboard interviews: yay or nay?

#28

Post by bhb603 »

> "Whiteboarding" has become too large of an umbrella term, one that groups together everything that's wrong with the interview process.

That general premise is right, we've lumped too much into the term "whiteboarding", and it's worth unpacking into the different interviewing practices we may like or dislike. Some things people don't like have nothing to do with an actual whiteboard (e.g. testing esoteric CS knowledge or deliberately creating a stressful environments), and some things that involve a whiteboard IMO are ok (e.g. sketching out a system diagram).

Re: Engineering whiteboard interviews: yay or nay?

#29

Post by pavel_lishin »

pmiller2 wrote: post #6
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…

“Jotting down some code on a whiteboard” with a colleague is a much lower stress scenario than deriving and writing down, under a time limit, some DP algorithm you might not have used since college, and proving its correctness and run time to some stranger who may be barely out of college themselves.

I don't think people should play CS-quizshow during whiteboard interviews. Being asked to implement a breadth-first search, or whatever, is kind of annoying - especially since there's effectively one correct answer. At best, you're testing my memory and whether I read the right interview book.

I had to do that at my last interview. I got through it ok-ish. The more interesting question was a more general system design question - how would I architect a system to do X, under constraints Y and Z. What would I do if a new constraint came up? Ok, now how would I make it more resilient? There, the whiteboards is just a tool I can use, not the primary focus.

Re: Engineering whiteboard interviews: yay or nay?

#30

Post by ubernostrum »

iamNumber4 wrote: post #24
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?

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 before, can you match or beat the absolute best solution the world's best CS researchers have ever come up with, in twenty minutes, on this whiteboard". If you aren't able to, they label you a bozo who can't even write a for loop, and pronounce you unqualified to do any type of programming, and pat themselves on the back for having kept "fake coders" out of their company.

(and if you wonder how anyone ever gets hired there, the answer is: by cheating. If you're going to interview at one of those places, odds are their interview problem and an accepted solution will be online somewhere, so you just go look up and memorize)

Post reply on HN