Live data from Hacker News

Engineering whiteboard interviews: yay or nay?

keyvalues.com

81–90 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#81
post #18
post #11

Earlier quoted context omitted.

I guess it depends on the job, but for outage response, being able to understand a problem, and update or write new code in a reasonable amount of time is kind of a useful skill. Discussing it on a board with others can be useful, if the code isn't complex. Of course, that also depends on the environment; if you're in an environment can't actually push any code, even emergency fixes, quickly, then it doesn't help a l…

Do you design clever search algorithms during outages?

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.

Re: Engineering whiteboard interviews: yay or nay?

#82

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.

Re: Engineering whiteboard interviews: yay or nay?

#83
post #65

I've been on both sides of this. Whiteboard interviews are good for a couple of things: Can the candidate explain a problem on a whiteboard? Is his hand-writing legible? It's not sufficient to decide if someone can code. You want some actual code written by that person. And you don't need everyone on your team being able to explain things well on a whiteboard. Just try to figure out how they are thinking and how they…

[deleted]

Re: Engineering whiteboard interviews: yay or nay?

#84

Earlier quoted context omitted.

I don't think people should play CS-quizshow during whiteboard interviews. Being asked to implement a breadth-first search, or whatever, is kind of annoying - especially since there's effectively one correct answer. At best, you're testing my memory and whether I read the right interview book. I had to do that at my last interview. I got through it ok-ish. The more interesting question was a more general system desig…

Surely not BFS. That's something you can figure out from first principles and knowledge of some data structures like stacks and queues, but I'd expect knowledge of those data structures anyway.

I don’t care if candidates can figure out BFS under intense pressure in 30-60 minutes. That is nobody’s job anywhere ever. I want to know if someone can think creatively, if they’re a pain in the ass to work with, if they’re thoughtful and careful or if they shoot from the hip. Admittedly, these are hard to measure (which is one reason why I would support some kind of mild licensure, but that’s a different subject), but being able to derive BFS does not correlate with competence or ability. Maybe if you’re doing router hacking or something, I guess, but specific algorithms are so little of most developers’ careers.

Honestly, we all might as well read chicken entrails because that would be about as predictive as our current interview practices.

Re: Engineering whiteboard interviews: yay or nay?

#85
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?

This is incredibly common, and you tell the candidate in advance that they will be expected to give an n-minute presentation on a subject of their choosing (need not even be tech) so they can prepare.

Tell me this: when did a mob last ambush you at your desk and demand that you invert a red-black tree on a whiteboard that they happen to have with them right now? I'm guessing that never happens where you work. If it does then fair enough :-)

Re: Engineering whiteboard interviews: yay or nay?

#86
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 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 a team meeting with someone from product who will watch your demo of a potential new project/idea/concept.

Re: Engineering whiteboard interviews: yay or nay?

#87
post #81
post #18

Earlier quoted context omitted.

Do you design clever search algorithms during outages?

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?

Re: Engineering whiteboard interviews: yay or nay?

#88
post #82

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.

They might generally use a library that handles a lot of common usages for recursion, like traversing a tree for whatever reason.

A question I've had in an interview was what is the difference between recursion and iteration. Fairly easy to explain, including examples of usage.

Re: Engineering whiteboard interviews: yay or nay?

#89
post #60

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…

The point is that the interview style in question overemphasizes on-the-spot responses. How is prowess in a game of "gotcha" an important indicator of engineering skill?

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 playing a game of gotcha on the whiteboard, you need better interviewers.

Post reply on HN