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

Re: Engineering whiteboard interviews: yay or nay?

#311

Post by usrusr » Fri, Aug 10, 2018, 8:59 AM UTC

Random fun idea: pair whiteboarding, have one of the reviewers start improvising a solution (or put on a show of not having done it dozens of times before) and see how the candidate will contribute.

If the problem is not one of the standard ones (that will be perfectly memorized by desperate candidates, while rightfully confident ones may struggle), it will demonstrate understanding, not the irrelevant ability to sequentially write out code in an unfamiliar medium. After all, you probably don't want to hire those who have already been rejected so often that they can code on a whiteboard as if they did it all day.

Re: Engineering whiteboard interviews: yay or nay?

#312

Post by hvidgaard » Fri, Aug 10, 2018, 9:03 AM UTC

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…

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

They you are asking the wrong questions. I use whiteboard for developers, and for junior developers I give them a simple task such as reverse an array, turn a string into a palindrome (and explain what it is if they don't know). If they want to be a developer they must be able to solve those simple tasks. I don't really care how, as long as they think loud. Then I use it as a starting point for enhancement discussions, perhaps stack/heap questions, recursion, assignments ect. During all this I coach them, teach unknown concepts in simple terms - this is what they can expect when they ask their mentor a question so in that sense they get a feel for us too.

Some argue that it's still not good, and that we're filtering out people that work best alone. That is true, but that is by design. We work as a team, having 10 individual developers not working together unless forced is an architectural nightmare.

Re: Engineering whiteboard interviews: yay or nay?

#313

Post by hvidgaard » Fri, Aug 10, 2018, 9:11 AM UTC

cakes wrote: post #156

pkteison wrote: post #143

Earlier quoted context omitted.

Every time an interviewer has told me something like this, they then nitpick syntax and appear to be primarily concerned with "does my whiteboard code compile" sorts of problems. And getting stuck / asking for help feels like I get docked for getting stuck. Same with less optimized. So it's hard to trust such an explanation - clearly my interview would be better if I came up with the perfectly optimized solution, or…

This is generally the same experience I have had. I'll even talk through the assumptions (e.g. "Can we assume I know how to do argument checking?") and then after I've done the heavy-lifting of the problem-solving I'm now discussing how I didn't do something I brought up as an assumption. Also, generally, if I'm whiteboarding in front of my coworkers/team/etc. I'm discussing something I've thought about for more than…

Even if you didn't say

> Can we assume I know how to do argument checking?

I would probably question you at some point about a particular value of an argument and almost all candidates will get points for thinking out load that of course a NULL would get it crashing and that a simple check could stop it. Then it leads to discussion about how it should be handled. Sometimes a NULL means the program should cast an exception, other times it should just return without any side effect.

IMO the hate for whiteboard questions is really a symptom of poor interview technique.

Re: Engineering whiteboard interviews: yay or nay?

#314

Post by spike021 » Fri, Aug 10, 2018, 9:16 AM UTC

mrep wrote: post #255

spike021 wrote: post #226

Earlier quoted context omitted.

Incredibly different. I highly doubt a normal engineer is going to be giving a demo to their team with high stakes in the first three or so months. I understand if they're possibly a senior engineer, architect, or lead of some sort because they were probably hired with a plan to spearhead a specific project. I'd say in the average case a new engineer will have enough time to at least break the ice with their new team…

I gave a demo of my intro project after a month to my 100 person org at my last company and I was a new grad. In fact, when I was an intern, all interns did project demos at the end of their internship.

Was the presentation of that demo standing between you and being fired or keeping the job?

Re: Engineering whiteboard interviews: yay or nay?

#315

Post by ordinaryperson » Fri, Aug 10, 2018, 10:23 AM UTC

bcassedy wrote: post #293

madrox wrote: post #194

Earlier quoted context omitted.

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

But being a slow worker is going to be revealed during a whiteboard coding test?

All small programs are maintainable, no interview process will tell you if a developer can deliver large, complex programs that are clean, modularized and easy to maintain because there's no time to do something of the requisite size.

It's true there are experienced devs who suck, but that doesn't mean whiteboard coding is the process that filters them out.

Re: Engineering whiteboard interviews: yay or nay?

#316

Post by keeganpoppen » Fri, Aug 10, 2018, 10:27 AM UTC

Yhippa wrote: post #279

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 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 than you'd think), etc. as a fairly strong signal, as those sorts of things don't just happen by chance-- they are the byproduct of a culture of thoughtfulness (and thoughtful people tend to be thoughtful about most things).

Re: Engineering whiteboard interviews: yay or nay?

#317

Post by Ntrails » Fri, Aug 10, 2018, 11:30 AM UTC

pkteison wrote: post #143

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…

Every time an interviewer has told me something like this, they then nitpick syntax and appear to be primarily concerned with "does my whiteboard code compile" sorts of problems. And getting stuck / asking for help feels like I get docked for getting stuck. Same with less optimized. So it's hard to trust such an explanation - clearly my interview would be better if I came up with the perfectly optimized solution, or…

> clearly my interview would be better if I came up with the perfectly optimized solution, or gave a lecture on the options rather than trying to discuss options.

Right. And a competency based interview goes better if you have a perfect example for every question. But it isn't an auto-fail if some of your answers are mediocre

Personally though - I'd rather hire someone who is able to properly communicate their thought process over an imperfect solution, than someone who was unable to discuss/explain the perfect solution they scrawled down.

Re: Engineering whiteboard interviews: yay or nay?

#318

Post by newton10471 » Fri, Aug 10, 2018, 11:34 AM UTC

hfdgiutdryg wrote: post #299

jaredklewis wrote: post #276

Earlier quoted context omitted.

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, a…

hfdgiutdryg any chance you can find the link to that submission? It sounds fascinating, and I couldn't find it via HN search.

Re: Engineering whiteboard interviews: yay or nay?

#319

Post by kamaal » Fri, Aug 10, 2018, 11:37 AM 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…

>>The assumption that candidate should spend his/her valuable time preparing for someone's assessment is arrogant.

Plus, if some one has to 'prepare' for an interview that is supposed to test people's capabilities to do 'everyday' jobs, then you are hiring the wrongest possible people out there.

Re: Engineering whiteboard interviews: yay or nay?

#320

Post by rafiki6 » Fri, Aug 10, 2018, 11:51 AM UTC

redisman wrote: post #250

rafiki6 wrote: post #66

I feel like this topic comes up on HN every six months and we all lament the broken state of technical interviewing, and the ardent supporters of all the different styles come in and push their position based on success perceived from anecdotal evidence. I have a hypothesis that hiring a good candidate is mostly luck. When we view the hiring process in the context of what it actually is, a sales relationship, we real…

I think Google is seeing a positive signal on their hiring process because a) they get a high percentage of the best programmers applying there at some point in their lives, and b) they run de-facto IQ tests on the onsites to pick the cream of the crop from that pool. It might not be the "best" raw programmers (that's impossible to define anyway) but being able to perform well on the algorithm tests means the people…

Exactly. In general, if you do well it means you're probably pretty smart (whether you've memorized or figured it out on the spot). If you don't do well, it just means it's not your type of test most likely. I'd say this creates an opportunity for non-Google like companies to moneyball their teams and get some high quality talent at a discount because they suck at passing the Google filter. If these companies were smart, and considering how much luck is involved in the process anyway, they should look for a different set of criteria to evaluate a candidate on.