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

291–300 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#291

Post by gautamdivgi »

dingo_bat wrote: post #281
Tobani wrote: post #110

Earlier quoted context omitted.

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…

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

We do the same thing as well. As long as the candidate can explain their abstractions in pseudo code we are good. We also keep to a 1-1 between interviewer and candidate so that the candidate isn’t intimidated.

I’ve interviewed at Facebook as well and although the interview was not successful I have never been nitpicked about syntax and compilabiltiy/runnability of my whiteboard solutions. I came off with a very healthy appreciation of the way they try to engage the candidate and reduce stress.

Re: Engineering whiteboard interviews: yay or nay?

#292

Post by thaumasiotes »

jaredklewis wrote: post #276
achikin wrote: post #197

Earlier quoted context omitted.

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.

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

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

Re: Engineering whiteboard interviews: yay or nay?

#293

Post by bcassedy »

madrox wrote: post #194
ordinaryperson wrote: post #190

Having just been through this process (landed a new job after a 2-month search), the worst part about whiteboard coding is how humiliated you feel if you don't get it right or don't know where to start. Is it really necessary to do that to candidates? I've been doing this for 15+ years professionally, have a master's in CS and I struggled to answer many questions. Just stood there blinking like a goldfish. If compani…

Asking someone with your amount of experience a coding exercise is silly. You wouldn't have lasted 15+ years if you didn't know how to code. Spend more time evaluating the "softer skills," since more experienced engineers have a bigger impact on culture and process.

Length of tenure is definitely not a good enough gauge.

I've worked with folks with 15+ years that could technically code but they took eons to deliver and their solutions were unmaintainable. Some of them with advanced degrees too.

Small sample size, but the few folks I'm thinking of were such bad hires that could have been avoided if we had them write some code or put the proper emphasis on the coding exercise we had them do.

Re: Engineering whiteboard interviews: yay or nay?

#294

Post by SomewhatLikely »

vultour wrote: post #165
privacypoller wrote: post #57

All of these interviewing "tools" (or tricks) attempt to be time/cost efficient proxies for doing the damn job, and they all suck. * Whiteboard coding is awesome for software development shops that don't actually own computers or use punch cards to load programs. * Shared coding environments with a time limit works well when you want to double screen for someone who can also diffuse suspicious packages that arrive at…

Riddles are the worst, I was recently asked the "You have a 5 litre and a 3 litre container, how do you get 4 litres" question (never heard it before). It's so simple to figure out if you're on your own and just play around with the idea. When asked on the spot I just kept thinking "hey these people want an answer NOW, don't make them wait" while feeling their stare, and couldn't figure it out without help.

I have found the best course is to treat the interview as a situation where a colleague has come to me with a problem that we are hashing out together. I feel a lot less pressure with that mindset, though I do get thrown off by interviewers who take an adversarial approach. But I find this an acceptable loss.

Re: Engineering whiteboard interviews: yay or nay?

#295

Post by ggggtez »

tluyben2 wrote: post #235
ggggtez wrote: post #182

Earlier quoted context omitted.

I think it's trivial to code an optimal solution (and discuss tradeoffs) in 45 minutes on a whiteboard. It's just BFS or DFS. Of course most people prefer to interview in a language which is less verbose than C++, which saves time.

Perhaps it is trivial, but what's the point? If you can reason what algo to use and reason how to determine which one will be the most efficient of the two without testing them both (or explain the abstraction which allows you to test them both without significant overhead in code), it should be enough.

In theory there should be no difference between theory and practice, but in practice there is.

Re: Engineering whiteboard interviews: yay or nay?

#296

Post by ggggtez »

nybblesio wrote: post #113

A regular viewer of my daily Twitch programming stream (link is in my profile) asked me to solve a problem he was asked to whiteboard. He wasn't asked to draw diagrams or write pseudo-code so they could learn how well he communicated. He was asked to write the code and it was heavily implied that it must compile and run -- even though whiteboards don't do that. Here's my attempt: https://youtu.be/6LHqrxrC6Uo I solved…

I skipped around on the video. You'd literally have 1/4 the code if you just coded a graph correctly.

You also keep a "counted" and "visited" variable separately for no reason. There is no reason to visit a node and not count it, and you can't count a node you didn't visit. Whatever optimization you think you are getting surely isn't worth it.

Re: Engineering whiteboard interviews: yay or nay?

#297

Post by raz32dust »

Whiteboard is GREAT for communicating design or technical ideas (e.g, what is consistent hashing, can you show how you'd merge N sorted lists schematically?). And these skills are super important in both big companies and startups. And we should definitely test candidates in these areas using whiteboards.

Making engineers write code on whiteboard is just comical. If we weren't so used to it, we'd probably have laughed at the idea. In 2018, any company still using whiteboards to write anything more than pseudocode is just playing it too safe or being really lazy in changing their process. Just give them a laptop and have them use coderpad/skype interviews or any of the plethora of collaborative code editors out there. Or even, dare I say, an IDE. You can still have the whiteboard in the room to discuss the idea. But write the code on a laptop with internet access.

Re: Engineering whiteboard interviews: yay or nay?

#298

Post by relate »

I've done whiteboard only interviews, as well as shared doc/coderpad only, and I find both limiting. When thinking about the problem, it's great to have a whiteboard to sketch examples etc, but writing code is much easier with a text editor.

Recently I interviewed at Google, and they had no problem fulfilling my request to do both: sketch the solution approach on whiteboard and then write the code with a laptop.

Re: Engineering whiteboard interviews: yay or nay?

#299

Post by hfdgiutdryg »

jaredklewis wrote: post #276
achikin wrote: post #197

Earlier quoted context omitted.

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.

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

That’s just interviews.

Nope. There was a great submission a few years ago about a guy who applied to two categories of jobs: management and software development.

In the SD roles, everything was oriented toward rejecting him. Any possible "red flag".

In the management roles, the interview was focused on finding areas where he could contribute to the company.

Whiteboard interviews are a problem in and of themselves, and the propagate terrible attitudes into the rest of the interviewing process.

Re: Engineering whiteboard interviews: yay or nay?

#300

Post by tluyben2 »

ggggtez wrote: post #295
tluyben2 wrote: post #235

Earlier quoted context omitted.

Perhaps it is trivial, but what's the point? If you can reason what algo to use and reason how to determine which one will be the most efficient of the two without testing them both (or explain the abstraction which allows you to test them both without significant overhead in code), it should be enough.

In theory there should be no difference between theory and practice, but in practice there is.

Obviously, I didn't mean that. Just from a white boarding perspective, that should be enough. Give the applicant a computer and have her implement it.
Post reply on HN