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

281–290 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#281

Post by dingo_bat »

Tobani wrote: post #110
spike021 wrote: post #86

Earlier quoted context omitted.

>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. I think it's safe to say that being put on the spot in front of people you don't know who are judging you is quite different from being put on the spot in…

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

If only all interviewers were like you.

Re: Engineering whiteboard interviews: yay or nay?

#282

Post by florabuzzword »

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

My experience agrees with this. I am a different, significantly less comfortable person to be around when strangers are asking me so many questions about myself. I think it’s just about the worst way to get to know me.

When I get hired this way, I always feel a little bit of guilt because I know they actually hired somebody else.

What can be done? I’m not sure, but I can say one thing: my level of discomfort is multiplied by the number of strangers in the room. Does this ever get considered with interviews?

I am far more comfortable coding in front of 1 or 2 people who each give me a little bit of background about their coding experience; just so I know. If they are experienced engineers, it’s probably not going to change what I say aloud, but it just makes me more comfortable. I guess more overlap of technologies in our background does help. It’s nice to not feel pressure of worrying if my solutions reflect general programming conventions enough to be language agnostic. I have never really used Java, for example.

Re: Engineering whiteboard interviews: yay or nay?

#283

Post by gregrata »

So I've been frustrated by this type of interview for years (on both sides, but the last 10 years on the hiring side). I don't think it's great finding people that are good at writing software (as it's a LOT more than a single algorithm and more than just coding).

I wrote a book it - along with what I've been using the last few years, that actually seems to work - or work at least a bit better. In the end, I don't think you really know unless you work with someone.

https://www.amazon.com/dp/B07FJ6N8P1

It's my first attempt at a book (small as it may be!) - I'd really appreciate some feedback (and it's free right now)

-Greg

Re: Engineering whiteboard interviews: yay or nay?

#284

Post by seanmcdirmid »

nerpderp83 wrote: post #275
seanmcdirmid wrote: post #132

Earlier quoted context omitted.

Then test that. Having someone code on a whiteboard, even if they are explaining what they are doing while they go along, is simply not the same thing as being good at using on the fly visual aides while communicating. In any case, that isn’t coding either.

You have 40 minutes to make a slide deck that explains bloomfilters and 5 minutes to present in front of the director of engineering.

That is the same as saying who can code the fastest rather than who does the best job. But at the PhD level there will be a presentation given regardless.

Re: Engineering whiteboard interviews: yay or nay?

#285

Post by dingo_bat »

crsv wrote: post #82
ngngngng wrote: post #48

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

You have a software engineering job and you never used recursion of any kind? This strikes me as super odd.

It's almost always a norm that you never use recursion in production code. Always convert it to iteration. Bounded iteration.

Re: Engineering whiteboard interviews: yay or nay?

#286

Post by itronitron »

Tobani wrote: post #110
spike021 wrote: post #86

Earlier quoted context omitted.

>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. I think it's safe to say that being put on the spot in front of people you don't know who are judging you is quite different from being put on the spot in…

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…

You are asking the candidate to compartmentalize their thoughts to solve a toy problem during a period of time when they are attempting to put various nascent clues about your organization together in order to form a better understanding and to identify how they can provide value / fit into the flow.

Fizz-buzz tests have their place, but I think an onsite interview is past that point. In general I have found that white board exercises don't allow me to either understand or convey how I can apply my expertise to provide value for the organization.

Re: Engineering whiteboard interviews: yay or nay?

#287

Post by hueving »

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…

Ugh, communicating with a whiteboard has no overlap with developing a solution to a completely unexpected quiz (if you didn't cheat) on a whiteboard in front of someone scrutinizing your every move with your future career on the line.

Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not.

If you defend whiteboard leetcode using this excuse you are deluding yourself and you are part of the problem. The only thing the modern FANG interview hires for is people that can solve algorithms problems in a silo under pressure. No checks for software engineering skills, collaboration skills, testing skills, reviewing skills, and on and on...

The whiteboard interview is why so many engineers unexpectedly suck.

Re: Engineering whiteboard interviews: yay or nay?

#288

Post by anonytrary »

mmt wrote: post #186
anonytrary wrote: post #105

I'd propose a supplement for interviewing. If your company has at least one open-source repository: 1. Have a senior engineer chat with the candidate for an hour about a few bugs/features in the repository, and how the candidate would solve them. 2. If the candidate is promising, give the candidate a week or so to fix the bugs or implement the features. I think this would be a more relevant test than just giving them…

Make it a paid project, and it at least partially addresses the sibling comment's (valid, IMO) complaint that it filters out candidates that are otherwise in high demand. It would also provide a significant signal regarding valuing the candidate's time and effort [1], which would comply with the suggestion of another comment elsewhere in the thread. [1] As well as the additional signal of putting money, rather than j…

Companies already pay thousands of dollars (per candidate) to fly out, accommodate and feed candidates for on-sites, so this doesn't seem unreasonable. Similarly, phone-screens and other filters would be done before a paid task is given.

Re: Engineering whiteboard interviews: yay or nay?

#289

Post by dasil003 »

hueving wrote: post #287
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…

Ugh, communicating with a whiteboard has no overlap with developing a solution to a completely unexpected quiz (if you didn't cheat) on a whiteboard in front of someone scrutinizing your every move with your future career on the line. Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not. If you defend whit…

Agree with most of what you said except the conclusion.

The reason many engineers unexpectedly suck is because it’s a high paying job where performance is difficult to measure let alone predict.

White boarding interviews are a symptom of the problem, not the cause of it.

Re: Engineering whiteboard interviews: yay or nay?

#290

Post by itronitron »

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…

>> What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams?

In that case I would recommend reading the candidate's resume beforehand, look for prior experience publishing, presenting, or teaching and ask them about it.

Post reply on HN