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

Re: Engineering whiteboard interviews: yay or nay?

#351

Post by munchbunny » Fri, Aug 10, 2018, 7:32 PM UTC

ilikehurdles wrote: post #144

munchbunny wrote: post #89

Earlier quoted context omitted.

I tend to agree with (what I think is) the sentiment of some of the respondents in the article: if your whiteboard interview is a game of gotcha, then the problem is your interviewer, not the whiteboard. I think the complaint that programmers pretty much never have to think about code under pressure is a fair criticism. The whiteboard really puts you on the spot. But if it's your company and your hiring managers are…

State dependent learning is a bit of a factor too. I can count on one hand the number of times I’ve presented anything on a whiteboard at work, yet just about every company asks these questions during interviews. A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in. Whiteboard coding interviews are one…

> Whiteboard coding interviews are one thing that I have to go out of my way to practice for and get better at over time when interviewing (ie over the course of a few failed interviews). I don’t feel more skilled or smarter by the end of the set of interviews, but I inevitably do better at these kinds of problems.

You have a good point, I noticed this about myself as well. However, I don't think whiteboard interviews are special in that regard. I noticed that I got noticeably better at the "sit down and code me a simple web API endpoint" interview, and I got noticeably better at the systems design interview, and so on.

I do think that whiteboard interviews tend to lean very algorithm-heavy, which doesn't reflect the role's actual day to day. And practicing algorithm interviews really does feel like an inefficient use of time unless your role truly demands algorithmic proficiency (like if you're a graphics dev).

Re: Engineering whiteboard interviews: yay or nay?

#352

Post by woolvalley » Fri, Aug 10, 2018, 8:01 PM UTC

rightbyte wrote: post #322

woolvalley wrote: post #129

Earlier quoted context omitted.

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.

What? Just let the programmer to it in his homeland. Easy. Just as outsourcing. I wish this project approuch was more common. It would probably be cheaper than wasting time on multiple days interviewing reality shows where people are voted out one by one like some companies do it.

It doesn't work when they are already working in the foreign country. They aren't going to travel 12 hours to do a homework assignment for you legally.

Re: Engineering whiteboard interviews: yay or nay?

#353

Post by unrealchild » Fri, Aug 10, 2018, 11:40 PM UTC

We offer a whiteboard for the onsite if it will help a candidate communicate comfortably. Narrative is totally fine, gesticulations, metaphors, interpretive dance, whatever means of communication works to get the point across. We send out a small HW assignment before an on-site, after a phone screen. Not all candidates enjoy it, some expect an algorithm driven whiteboard experience. Our process delivers for us, and we tend to naturally attract a good culture fit as a byproduct.

In practice we do end up at a board day to day explaining ideas and so on, and everyone seems more than comfortable (with the exception of handwriting insecurity).

Re: Engineering whiteboard interviews: yay or nay?

#354

Post by loxias » Fri, Aug 10, 2018, 11:51 PM UTC

LaserToy wrote: post #238

loxias wrote: post #148

Earlier quoted context omitted.

I'm actively looking/interviewing and really like the "cut of your jib". (both your answers here, plenty of aspects of Eaze as a company, the prospect of moving back to SF...) For both the sr backend and devops positions, how important to the roles is familiarity/experience with your technical stack? I might have some of the skill set/experience you're looking for -- sr backend engineer, sr systems engineer, devops a…

Do you want to work for PlayStation Network team? We have plenty of open positions from DevOps to server or client side developers. And variety of work also there - commerce, social, video streaming, distributes databases, big data, ml. You name it, we are doing it.

Maybe? Sounds cool! Can you send me a very very short email (my email is on my HN profile page) as a point of contact for further communication?

Re: Engineering whiteboard interviews: yay or nay?

#355

Post by loxias » Fri, Aug 10, 2018, 11:52 PM UTC

techwraith wrote: post #151

loxias wrote: post #148

Earlier quoted context omitted.

I'm actively looking/interviewing and really like the "cut of your jib". (both your answers here, plenty of aspects of Eaze as a company, the prospect of moving back to SF...) For both the sr backend and devops positions, how important to the roles is familiarity/experience with your technical stack? I might have some of the skill set/experience you're looking for -- sr backend engineer, sr systems engineer, devops a…

We care less about your particular technical skills than we do about your generalized engineering skills. Specific stacks are easy to teach; fundamentals, emotional intelligence, and social skills are harder to teach. In fact, if someone is too into their stack, we see that as a bad sign. So I'd be super excited if you decided to apply :)

I'll submit a resume and a CV sometime late next week. :)

Re: Engineering whiteboard interviews: yay or nay?

#356

Post by screye » Sat, Aug 11, 2018, 4:05 AM 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…

I think now a days, selection through the whiteboard process simply comes first to how much you grind leet code and the like.

Ironically this leads to min- maxxers who ignore a good chunk of their courses simply to master leetcode. My smartest peers are ones who work on interesting projects and research, thus never finding time to grind interview questions.

Then there are also companies that expect your white board code to compile and have perfect syntax, which imo is very unreasonable.

Re: Engineering whiteboard interviews: yay or nay?

#357

Post by jarsin » Sat, Aug 11, 2018, 5:01 AM UTC

keeganpoppen wrote: post #316

Yhippa wrote: post #279

Earlier quoted context omitted.

I wouldn't go as far to say whiteboard interviews == bad company. I will evaluate the company if a whiteboard interview is run poorly however and consider it a bullet dodged.

going through / having just gone through this process this is where i've basically ended up as well... crappy interview experiences are universal enough that they don't disqualify a company automatically (though obviously i'm not terribly fond of them :-). the one thing i'd add is that i do take particularly thoughtful / empathetic interview processes, interviewers who actually know and understand the question (rarer…

I caught an interviewer red handed once by handing him the marker and asking him to show me. He tried and failed and then his coworker tried to fix his mistake and failed.

Ya I did not get that job lol.

Re: Engineering whiteboard interviews: yay or nay?

#358

Post by [deleted] » Sat, Aug 11, 2018, 5:31 AM UTC

[deleted]

Re: Engineering whiteboard interviews: yay or nay?

#359

Post by sam0x17 » Sat, Aug 11, 2018, 7:34 AM UTC

hobls wrote: post #260

mlthoughts2018 wrote: post #239

Earlier quoted context omitted.

Bad workplaces are so common though that it’s a perfectly good heuristic to guess that if a place asks you to do whiteboard questions it’s a bad engineering workplace. You’re not missing much by passing, and the heuristic probably won’t be wrong much.

I guess you think every major tech company is a bad engineering workplace? Seems like a broad brush.

seems true

Re: Engineering whiteboard interviews: yay or nay?

#360

Post by jkoudys » Sun, Aug 12, 2018, 2:26 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…

I agree, and as an employer I find a happy medium is to test on a whiteboard, but be completely okay writing filler, a comment saying "code for this goes here", etc. So long as they're building the correct general approach, that's all I need to see.

Whiteboard interviews where the interviewer says "it's actually `.toLowerCase()`, not `.lowerCase()`, you fool!", or "oops! You forgot to `position: relative;` the containing element that you `position: absolute;`d below!". you're not testing anything useful. Maybe if we were still coding everything on punchcards and using massive user manuals, but docking applicants for things their editor would highlight or one ctrl-r on the page would find is ridiculous.