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

211–220 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#211

Post by hackits »

lfowles wrote: post #15
pmiller2 wrote: post #12

Earlier quoted context omitted.

More stressful, sure. For many people, whiteboard coding is disproportionately more stressful than typical work, and that’s the problem.

One particular expectation when whiteboard coding for an interview is that there is little/no downtime, you must be making progress or talking about your thoughts. Incidentally, 50% of my thought process then becomes "How do I talk about what I'm thinking about? Oh no, I'm only thinking about talking about what I'm thinking about..."

For this reason I don't do living coding sessions. People have asked me `why` which I politely say the answer is no. They seem to like the boundaries I set for myself and my project's more than some sort of white board.

Yes, I've been turned down for jobs over the white board but I've had more positive results than negative.

Re: Engineering whiteboard interviews: yay or nay?

#212

Post by ordinaryperson »

optimuspaul wrote: post #38
devy wrote: post #9

Serious question, if whiteboard interview aren't the best or helpful at all, what are the successful/useful alternatives for engineering interviews?

The best I have come up with if you are requiring them to write actual code is to give them a problem to solve for with code prior to interviewing. Have them bring that code along and then have them explain the code and why they did things the way they did. It is not 100% verifiable that they wrote the code, but being able to talk to why things were done the way they were tends to be good enough. I have also found th…

Exactly.

During my recent job search I was asked many questions I didn't know the secret algorithm to, but if those companies had given me the problem ahead of time and allowed me to research it -- just like what happens in real life -- I could have coded solutions to all of them.

And if you're worried about people just plagiarizing existing solutions, have them talk through it, as you say. Should be fairly clear if they understand each line or not.

Re: Engineering whiteboard interviews: yay or nay?

#213

Post by amzn_82582 »

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…

Maybe I was just lucky, but I interviewed with google and dropbox recently and both companies gave me laptops to type in, did not ask me once about if my code compiled, didn't comment on my style, nor did I have to perfectly know the standard library (for google, they told me to just guess at the random library functions and I also forgot some of the functions names for a set. For dropbox, one of the guys re-explained to me semaphore functions and how they worked since I forgot since it had been so long since I used them in college). I passed both.

Granted, I will give you that optimized code has definitely been important. One of those interviews even had me use a bit array (at least I think it was that) to efficiently a store a list of booleans but at least they gave me the relevant function calls to use an already implemented one.

Re: Engineering whiteboard interviews: yay or nay?

#214

Post by hackits »

ubernostrum wrote: post #36
lfowles wrote: post #15

Earlier quoted context omitted.

One particular expectation when whiteboard coding for an interview is that there is little/no downtime, you must be making progress or talking about your thoughts. Incidentally, 50% of my thought process then becomes "How do I talk about what I'm thinking about? Oh no, I'm only thinking about talking about what I'm thinking about..."

I'm working on a large-ish project right now, and into one of the more tricky bits literally today. And you know what? I take breaks. I go read something on the internet or post a comment, or I go for a walk, or I go do one of the smaller housekeeping tickets I keep in my queue to give my brain a rest from continually focusing on the hard parts of the problem. Can't do that in a whiteboard session.

Most of the time their technology stack with be vastly different than anything else you've worked with. There will be other people you will need to discuss and coordinate with. Articulating your thoughts and expressing yourself clearly and concisely is more important.

Vast majority of the technical problems have been solved and its delivery a solution to a business problem that is the most important aspect.

Re: Engineering whiteboard interviews: yay or nay?

#215

Post by pmiller2 »

vkou wrote: post #179
stlHusker wrote: post #31

Earlier quoted context omitted.

"Interviews are necessarily more stressful than typical work. That's not just a property of whiteboard coding." My sister, a pediatric ER nurse would disagree with you. The interviews are largely behavioral and are a breeze. No dummy is wheeled in with head trauma, random "new" diseases aren't invented and asked to be treated, etc. The simple fact of the matter is if hospitals hired in the same way, they would have n…

That's because she's already went through all that stress and bullshit and skills testing in med school and residency. If any clown could call themselves a nurse, and would apply to ER nurse jobs, it would take all of ten seconds before nurses would have to do whiteboard triage interviews. I have no idea what the candidate did in their CS undergrad. Maybe they cribbed all their work from their roommate. Maybe they we…

At least a test of triage skills would be a real world skills test. The equivalent for most whiteboard software engineer interviews would be a quiz on cellular biology.

Re: Engineering whiteboard interviews: yay or nay?

#216

Post by deskamess »

If someone gets hired, and on the job in the next year, they do not implement/discuss the interview questions in any non-interview situations, then drop those interview questions. When a candidate fails to answer a question/task, ask the co-worker who asked the question/task to complete it (and be just as strict with them).

Re: Engineering whiteboard interviews: yay or nay?

#217

Post by stevenwoo »

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…

How do you interview candidates for your company?

Re: Engineering whiteboard interviews: yay or nay?

#218

Post by mrep »

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…

Really? I have multiple in person discussions per week about how we are going to tackle some problem where everyone chips in and those are just the weekly problems we are working towards. There are also the much larger design docs and while some of the feedback on those happens asynchronously, a lot also happens in real time during meeting reviews. Oh, and both of those problems are decently well covered by your standard interviews (the former generally being data structure/algorithm design, the latter generally being system design).

Re: Engineering whiteboard interviews: yay or nay?

#219

Post by jpindar »

recursive wrote: post #7
pmiller2 wrote: post #6

Earlier quoted context omitted.

“Jotting down some code on a whiteboard” with a colleague is a much lower stress scenario than deriving and writing down, under a time limit, some DP algorithm you might not have used since college, and proving its correctness and run time to some stranger who may be barely out of college themselves.

Interviews are necessarily more stressful than typical work. That's not just a property of whiteboard coding.

As an embedded systems engineer, I disagree. I have never been asked to design a circuit, or even pseudocode firmware, on a whiteboard. In the electronics manufacturing industry, interviews consist of talking, mostly about projects I've worked on before and projects they've done before. Occasionally someone will give me the same written test they give technicians, but those tend to be pretty easy.

Re: Engineering whiteboard interviews: yay or nay?

#220

Post by [deleted] »

pdxandi wrote: post #171
jihoon796 wrote: post #167

If you must do whiteboard interviews, here's a technique I've used with great effect: Have someone else pick a coding problem (that you as the interviewer don't know beforehand), and work on it from scratch together with the candidate. Being upfront with the candidate that you don't know the answer yourself puts the candidate at ease, and you'll be able to better judge the candidate's soft skills (communication, crit…

I like this idea. Personally, I struggle with knowing that the interviewer knows the answer. My wife's in medicine and she and her colleagues call this process "Guess what I'm thinking?" I prefer to have dialog and come to a conclusion together, and I feel it gets what you want out of an interview: how does the candidate think, how deep is their understanding of the technology, how do they communicate, and would you…

[deleted]
Post reply on HN