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

31–40 of 370 posts

Re: Engineering whiteboard interviews: yay or nay?

#31

Post by stlHusker »

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.

"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 no staff.

Re: Engineering whiteboard interviews: yay or nay?

#32

Post by renegadesensei »

They're fine but they need to be understood properly. Whiteboard interviews don't really capture how well someone codes. They are better at capturing thought process, high level understanding, system architecting ability, and a candidate's communication skills.

If you want to see how well someone codes, look at their code. Or ask them to write something for you. Don't do a whiteboard interview and think it is the end all be all. Take it as a data point.

Re: Engineering whiteboard interviews: yay or nay?

#33

Post by privacypoller »

pavel_lishin wrote: post #3
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…

Minor kvetch: quoting the way you did it makes long lines very difficult to read. I usually quote like this: > I am a quote This makes the quotation doubly-distinct, and still readable on mobile devices. === To the actual point I wanted to make: plenty of engineers at companies code on a whiteboard. They schedule a meeting, grab a room, and talk things out, while making notes, diagrams and sometimes even actually wri…

I don't doubt lots of companies do this, but I skeptical about the coding on a whiteboard. They talk in person, sketch out diagrams, highlight important aspects - why? because these things are all easier on a fluid analog medium like a whiteboard or piece of paper.

Actual Code? Not a chance. Portability, Durability, Efficiency - It's the worst of all worlds.

Re: Engineering whiteboard interviews: yay or nay?

#34

Post by dionidium »

pmiller2 wrote: post #6
pavel_lishin wrote: post #3

Earlier quoted context omitted.

Minor kvetch: quoting the way you did it makes long lines very difficult to read. I usually quote like this: > I am a quote This makes the quotation doubly-distinct, and still readable on mobile devices. === To the actual point I wanted to make: plenty of engineers at companies code on a whiteboard. They schedule a meeting, grab a room, and talk things out, while making notes, diagrams and sometimes even actually wri…

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

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

I'm not opposed to white-boarding, but to reinforce this point I'll note that I would have done much better on some of these problems when I was just out of college than I would today, because they were all fresh in my mind.

I assure you I wasn't a better programmer or employee then.

Re: Engineering whiteboard interviews: yay or nay?

#35

Post by haeffin »

denzil_correa wrote: post #27

In general, an interview is to understand what a candidate brings to the table. Therefore, one of the best ways to assess "glass half full" is to talk about their past work. The interviewer is a subject matter expert who can definitely ask pertinent questions about the candidate's work. In many cases, more so for scientific positions - the candidate's work is publicly available. Currently, many interviewers go for -…

Unfortunately, some companies' HR departments actively encourage "trivia questions", because they ask interviewers to ask every candidate the same questions so that a "fair" comparison between candidates.

Re: Engineering whiteboard interviews: yay or nay?

#36

Post by ubernostrum »

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

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.

Re: Engineering whiteboard interviews: yay or nay?

#37

Post by miah_ »

h4b4n3r0 wrote: post #14

Nay, unless the candidate wants the whiteboard. Even Google doesn't mandate whiteboard anymore: you can write your code on the provided Chromebook. Some people choose whiteboard, though, for reasons unknown. I think whiteboard (or a sheet of paper) is reasonable for what it gets used for IRL: for sketching out what you're going to do, by drawing or writing very high level description, but it sucks for everything else…

I did a interview with Google last summer. They didn't use a whiteboard, but instead had me code in a shared GoogleDoc. Pretty similar issue, limited time, somebody staring over your shoulder, not your usual development environment. Even more frustrating when you _know_ they have a web-based IDE for internal software development but make you write code in a GoogleDoc.

Re: Engineering whiteboard interviews: yay or nay?

#38

Post by optimuspaul »

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 that understanding how people approach life and problems in general are more telling of how good they will be than actually evaluating their coding skills. Monitoring coding exercises will weed out many good candidates as well as the poor ones in my experience.

Re: Engineering whiteboard interviews: yay or nay?

#39

Post by romille »

To me, it's not about the code on a whiteboard vs a computer and correctness.

It's about the thought process when breaking down a problem and the ability to organize and communicate their thoughts. It's also about exploring a problem space. How carefully does an engineer consider edge cases? What kinds of things are important to them?

A whiteboard to me is a much simpler and accessible medium through which to explore a problem vs setting up an environment and having to type code and dealing with all the minutiae that comes with actual development.

Of course, it isn't the ultimate method of evaluating a candidate but it's certainly valuable.

Post reply on HN