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

Re: Engineering whiteboard interviews: yay or nay?

#121

Post by anonytrary » Thu, Aug 09, 2018, 9:00 PM UTC

Whiteboards, in practice, are never used for writing strict code. They're used for high-level diagramming and high-level pseudocode.

The only time I've used whiteboards in my job is either when I need to hash out a solution or approach with my coworkers, because I'm confused or don't understand the problem, or when I need to understand high-level architecture for a system. It's a tool for clearing one's thoughts and for getting a team "on the same page".

If you're hiring someone to code-monkey a bunch of JIRA bugs, then whiteboarding might not be a relevant test for them. If you are hiring someone to build out new features efficiently or redesign architecture, then whiteboarding may be useful for having them describe at a high-level how they would solve problems. In both cases, writing syntactically flawless solutions on a whiteboard is a waste of time for both the interviewer and interviewee.

Re: Engineering whiteboard interviews: yay or nay?

#122

Post by dvdhnt » Thu, Aug 09, 2018, 9:01 PM UTC

Yeah, no. At least, not to test the technical proficiency of a potential team member.

Instead, have a conversation about how to solve a well defined problem. Use the whiteboard to record potential solutions in high level terms, or if the candidate chooses, to note key concepts or concerns.

Your interview environment should be a "staging" environment for your day to day operation. The interview should gauge how the candidate might affect your development process.

Once the interview ends, snap a picture of it. When you're debating candidates and try to remember your impression of them and how they contributed. Consider the sum of the input they verbalized and the input they wrote. That should give you a good idea of what they'll offer - well, along with your impression of them to that point.

Re: Engineering whiteboard interviews: yay or nay?

#123

Post by liquidise » Thu, Aug 09, 2018, 9:02 PM UTC

Whiteboard coding measures penmanship while nervous.

I have some firmly held opinions [1] on this topic. Interviews are too much of an "art" for how important it is that their results be repeatable. Keep them on topic as much as possible. Making a coder perform circus acts on a whiteboard they will never be asked to do otherwise is simply measuring for skills you don't need.

1. https://blog.benroux.me/whiteboard-coding-measures-penmanshi...

Re: Engineering whiteboard interviews: yay or nay?

#124

Post by dave_sid » Thu, Aug 09, 2018, 9:03 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…

Coding on a whiteboard while being questioned by two or more interviewers isn’t really a true representation of a work situation. It’s always more stressful and some people thrive on it, some people don’t. Im not sure what the better alternative is to demonstrate verba/technical communication skills however. The problem is, it’s hard to figure out if someone is a good fit with just a couple of hours of vigorous questioning. Maybe that’s the problem. I’d say I’ve worked with plenty of colleagues where it took me weeks or months to fully appreciate how extremely valuable they are to the team.

Re: Engineering whiteboard interviews: yay or nay?

#125

Post by remoteorbust » Thu, Aug 09, 2018, 9:03 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…

> It's bizarre to me that you think that whiteboard coding tests "communication", in any way. It's not like a presentation, or anything.

I feel like we're probably at an impasse if I can't convince you that a whiteboard is a decent medium to communicate ideas around datastructures and algorithms, but I appreciate your point of view.

I can only say my experience, which I hope you will take into account as one anecdote. I don't read books about "cracking the coding interview" or do leetcode or hackerrank. I left school 14 years ago or so my stash of cs trivia/secrets/gotcha isn't particularly full. I've done whiteboard interviews where I come up with at best a naive solution.

And yet I've received offers for fairly senior engineering positions at Amazon and Twitter and (hopefully tomorrow) from Google. Most of the whiteboard interview isn't even around the code, although that's a small part. Most of it is analyzing the problem, discussing constraints, discussing tradeoffs, walking through data structure manipulations, drawing arrows and boxes, that kind of stuff. Some code, maybe 30% of the interview. I just keep having this experience where nobody wants to play the gotcha game, they want to know how well I can communicate while solving a problem and they think they get that information out of the interview (I agree with them).

That experience makes it hard for me to understand a viewpoint that believes that whiteboard interviews are about memorizing secrets in advance.

Re: Engineering whiteboard interviews: yay or nay?

#126

Post by scott_s » Thu, Aug 09, 2018, 9:03 PM UTC

jiveturkey wrote: post #117

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…

It makes you someone that can't listen. The most important part of communication is listening. When the interviewer asks you to whiteboard a problem, they aren't asking you to "solve it". Obviously, you only have a whiteboard and you only have 15 minutes max. You might throw out some comment about size vs. time (eg) but make the decision and move on, quickly. The interviewer might decide to latch on but if not, you h…

The scenario nybblesio describes ("asked to write the code" with expectation it would be able to run) is not the one you described ("they aren't asking you to "solve it").

Re: Engineering whiteboard interviews: yay or nay?

#127

Post by balls187 » Thu, Aug 09, 2018, 9:04 PM UTC

LaserToy wrote: post #99

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

> So, why should I prepare for Google's or someone's else interview?

Because you want the job? Everyone is busy, that's a terrible excuse not to brush up on your interview skills.

By the tone of your post, my sense is that prior to your recent epiphany you weren't very kind to candidates who you interviewed.

Re: Engineering whiteboard interviews: yay or nay?

#128

Post by LaserToy » Thu, Aug 09, 2018, 9:04 PM UTC

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…

How many times did you solve a real problem with capturing all the edge cases in less than 45 minutes?

Re: Engineering whiteboard interviews: yay or nay?

#129

Post by woolvalley » Thu, Aug 09, 2018, 9:06 PM UTC

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…

The issue with a paid project is you can't legally do it with people on work visas, which is a large part of your interview pool.

They are all imperfect proxies due to various constraints.

Re: Engineering whiteboard interviews: yay or nay?

#130

Post by emmelaich » Thu, Aug 09, 2018, 9:07 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…

Yes!

What you're testing is the ability to discuss a problem with your peers. That is the critical thing.

Do the whiteboard but don't make the coding the standard. Don't get too hung up on the details of the problem.

Make the problem easy but fuzzily specified.