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

171–180 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#171

Post by pdxandi »

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 enjoy working with them.

Re: Engineering whiteboard interviews: yay or nay?

#172

Post by toast0 »

throwawayboye wrote: post #87
toast0 wrote: post #81

Earlier quoted context omitted.

If the existing search algorithm is the cause of the outage, maybe. If I a clever search algorithm will help me filter the data so I can reduce the scope of the outage, yes.

Are there no existing tools to search through data?

Everything is already implemented, let's close the patent office.

Re: Engineering whiteboard interviews: yay or nay?

#173

Post by dpiers »

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.

I can only think of a couple occasions in my professional career where recursion made more sense than iteration. Both involved traversing trees with unknown depths (parsing XML and scanning a file system).

That hasn't stopped it from showing up in every programming interview I've ever done.

Re: Engineering whiteboard interviews: yay or nay?

#174

Post by keithnz »

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?

Depends on "why" you are recruiting and what the end result of employing someone is.

So much of the technical hiring process tends to be about trying to find people that match what you expect people to be. Which might be fine, you need to fill a particular position which requires a specific set of skills. You need to validate those skills. You do that by doing something semi realistic while trying to minimize the pressure of an interview situation.

But, then there is the other kind of approach where you are looking to see what the candidate can offer, trying to find people who know different things to you and do things differently than you, in this scenario you are more inquisitive and let the candidate direct the interview process and get them to show you things that sound interesting (including coding).

The first approach is all about finding specific skills. The second approach is all about being clear about the values you are looking for.

The second approach requires more skill and more time while wearing the hat of a technical recruiter.

You may need a little bit of both approaches.

So the big thing is to be clear about who you want to work with at the end of the process.

Re: Engineering whiteboard interviews: yay or nay?

#175

Post by lev99 »

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…

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

I do coding interviews in the following manner: I select an interesting problem from a book. I personally complete the problem, measuring what was challenging and the time it took for me to complete the problem. I check the textbook solution, making notes of how my solution differs from the textbook's. If I like the problem, and if it fits with the development role, I invite the candidate to bring a development laptop, I give them a hard time limit of twice the time it took me to complete it, and have them share their screen while they attempt to complete it.

Afterwards we test their solution, I ask them some questions about it. I grade based on code taste, the number of hints they need, and their completion time. All candidates for a position are given the same question. Performance in coding interview is about two third's of the overall candidate evaluation. The ability to sit down and write good code in a time constraint manner is a very important part of being a developer.

Re: Engineering whiteboard interviews: yay or nay?

#176

Post by dqpb »

I think most people that are opposed to coding interviews feel that way because they don't feel confident in their ability to do those interviews well, whereas they do feel confident in their ability to "get work done".

Here's the thing though. Let's say you're the one giving the interview to two people who claim to be able to get shit done. One is able to code up a solution quickly and the other struggles, producing less, or producing something that's flawed. Sure, that second person might actually be productive under the right circumstances, but that doesn't matter because the first person already proved they can code.

That's the whole point of interviews, getting high signal in a short period of time. If you think coding interviews don't provide high signal than propose something better that costs the same amount of time.

Re: Engineering whiteboard interviews: yay or nay?

#177

Post by ztjio »

romaniv wrote: post #23
teachrdan wrote: post #5

Earlier quoted context omitted.

There's some logic to that. It's the one of the same reasons we have high stakes exams in school: to show what the individual can do under pressure. In an interview setting you can't simulate what it's like to be at the end of a high-intensity sprint, but you can ask the candidate to answer a tough question on a whiteboard and (ideally) get a notion of how they work when the going gets tough.

The pressure of a whiteboard interview has nothing in common with the pressure of a short deadline. It's like testing people for Tour de France by putting them on a unicycle.

Now there's a prologue I'd actually watch.

Re: Engineering whiteboard interviews: yay or nay?

#178

Post by ggggtez »

>Software engineers hate whiteboard interviews. How do I know? We continually tell complete strangers just how much we hate them.

And yet, whiteboard interviews are probably 3rd on the list of flamewar topics behind vim, and whitespacing. So there is clearly some people who don't hate them.

I count myself in the camp of people who don't relish the world before fizzbuzz.

Re: Engineering whiteboard interviews: yay or nay?

#179

Post by vkou »

stlHusker wrote: post #31
recursive wrote: post #7

Earlier quoted context omitted.

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

"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 went to a party school. Maybe they spent the last 4 years as a 'Senior Developer' at FooCorp copying files from hard drives to floppy disks, and posting a few paragraphs a day on the company's WordPress install. Maybe they are an Architecture Astronaut who can talk for six hours about how great Haskell is at doing multi-manifold monadic trivariable entaglement, but has no idea how to do any real work.

Or maybe they spent the last decade building Bigtable and MapReduce, and Spanner, and TensorFlow at Google. I'm not an expert on Bigtable, or MapReduce, or Spanner, or TensorFlow, though - and I can't definitively, in 60 minutes, tell if the person I'm talking to is bullshitting me. I can't tell if they actually did any of that work, or they coasted. I can't tell if the complicated problem they are describing to me is actually hard, or if they are embellishing it. Even if I felt confident that I could make that conclusion, my opinion would be incredibly colored by personal biases.

Oh, I should check their GitHub, you say? Well, guess what - Jeff Dean - the guy who did spend the last decade building Bigtable and Mapreduce, and Spanner, and TensorFlow - doesn't have a GitHub account. Presumably because he has better things to do with his free time, then work on OSS.

Oh, I should hire fast and fire fast? Don't get me started on why that doesn't work...

Re: Engineering whiteboard interviews: yay or nay?

#180

Post by fareesh »

I generally ask candidates what they did last week at their existing job, and then ask questions about how they solved specific aspects of that particular job.

If the person says "we built real-time tracking for our in-house vehicle fleet", I will just probe further and further about what role they played and how they went about the specific implementation details.

If there is any kind of secrecy surrounding their work, I will simply offer them insight into what they'll be tasked with during their first week and ask questions in a similar manner.

I'm not sure what advantage any other approaches have - I am hiring to fill a particular position. It's quite likely that the candidate will be in a similar position, so either I ask them about their current work and how they went about it, how they intend to accomplish the work assigned to them when they work with me.

Post reply on HN