Engineering whiteboard interviews: yay or nay?

A couple of comments have mentioned LeetCode. While reading those comments I had an odd idea on a different way to use LeetCode when interviewing. The usual way would be to get problems from them and spring those on the candidate to solve on a whiteboard or on a computer. Numerous people have raised objections to that kind of interview.

Instead, how about sitting down in front of a computer with the candidate, going to an interesting problem on the LeetCode site, and reading the problem statement with the candidate. Make sure you both agree on what the problem is asking for.

Then, instead of having the candidate solve the problem, go to the discussion page for the problem, and start reading the posts with the candidate. These will include posts from people who are asking for help understanding the question, and from people who are showing off their solutions.

Pick a few where the poster is asking for help understanding, and ask the candidate how they would clarify things for the confused poster.

Pick a few where the poster is posting their solution, and ask the candidate to do in informal oral code review along with you. Let the candidate take the lead, just providing nudges if necessary. For ones where the review finds serious bugs, talk about how to make test cases to demonstrate the bugs.

From what I've seen on LeetCode problem discussions there will be a lot of posted solutions that have edge cases that fail, or fail to meet time or space requirements that were given, or leave out major cases, or make implicit assumptions about the input that if violated invalidate their sultion. There should be no problem finding plenty of posts with plenty of things to bring up in review to discuss with the candidate.

This seems to me that it would not be overly stressful on the candidate (way less stressful than writing code under a short deadline), it is exercising skills that working programmers actually use, and it would let you do some work with the candidate to get some idea of how they get along with others when working.

I agree. I interviewed people who optimized for white boarding interviewed and, as such, could knock up CS algorithms which you can trivially import from libraries all I wanted. But when asking them a problem they did not encounter before and Google, they got very stuck. While, every time, there was a way of writing the query to Google that had the answer in the top 3 (usually #1). People waste crazy time on reinventing the wheel.

Anecdotal: we had some problem to solve which required qua a lot of code to solve and only old sites with broken links came up in Google for the guy solving it so he decided to implement it himself. When I asked why that task was taking so long he showed me what he was implementing. The code he was writing had an implementation on an old site which had a broken link to the code; when I copied the name of the zip file that was linked in github; there was the code. It had no description or comments; someone just checked it in. It was not perfect code, but it shaved off a few days of writing it from scratch anyway.

I care about being able to code, which can be assessed from past code and a pair programming session and then efficient problem solving using your brain and internet. The latter is somehow less common.

So my favorite way now is; I ask them to 'solve' a problem they have never encountered and that cannot physically be done during the interview time (I am interviewing for software development and in our field you get asked for things that cannot be done in the time you are asked to do it all the time, so I need to see how you handle that); give them time to Google possible ways to do it and present a little plan. Then they need to pick, out of the plan, something they think they can do inside the interview time (see how confident they are and if they have any sense about low hanging fruit or estimations; I might suggest something else if the task they pick is only installing libraries for an hour ;) and we'll sit together behind a monitor and do it together. I'll usually tell them to stop after 15-30 minutes as I have seen enough at that time.

As a senior-level self-taught, I redacted this post because of my views on whiteboard coding. Downvotes are not cool.

I don’t think there’s much criticism of those types of whiteboard interviews. I’ve had programmer interviews that involved sketching out a system architecture or database scheme on a whiteboard, which I think is perfectly reasonable.

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 in general are highly intelligent.