Engineering whiteboard interviews: yay or nay?

Well, yeah, other than tail recursion with tail call optimization, stack consumption, if not stack overflow, is always an issue.

> and honestly many recursive algorithms are quite hard to parse in your head especially once you add some edge cases and some other entropy.

I find lot of things are easier to conceptualize recursively than iteratively, though parsing really depends a lot of the language.

If the interviewer leaves frustrated because they couldn't solve anything and it was a mess, or the question was formulated terribly, or the interviewee was under prepared, etc etc, then it provides a lot of insight into the capabilities of the interviewee. It almost provides more insight into the qualities required of a developer than just putting them on the spot.

But instead of acing it an issue cropped up in the coding pad which I had to try and debug, which threw me off guard. The interviewers had muted their mic and were chatting away and my nerves just crumbled and I ended up profusely sweating into my eyes, I literally had sweat going into my eyeballs. I just turned into a bit of a mess, which is strange for me as I'm normally quite confident.

I think if the interviewers were a bit more involved it may have gone better. But I ended up just not finishing in time feeling like I had wasted everyone's time.

A whiteboard interview isn't a good growth indicator, but it's great at leveling a candidate. Moreover, it signals to a candidate that their peers will be at a similar level.

So I'd vote yay. If you pay attention, you can determine someone's proficiency at coding on the whiteboard in about 15 minutes. This is particularly important when you have people who are changing careers or junior or otherwise don't fit the mold.

I'm honestly shocked at the arguments against whiteboarding as many of them seem entirely reactionary.

"But I'm never going to work that way."

Didn't we all do the better part of two decades of formal schooling? We test people like that for a reason: you can carefully focus on the specific markers of mastery of a subject.

I understand why people make this argument: it's a reaction to some of the weird puzzles companies used to ask. But it's never substantiated that this will help the interviewer and candidate make a better decision, so it has the same problem the puzzles did.

"But at work I have Google and StackOverflow."

This is a good point, the questions you ask in a whiteboard question should be based on the fundamentals rather than trivia. But it's a terrible point because it accepts that the interview is just a ritual you go through and this argument is that we should make it fair.

Whether a candidate knows "the answer" is not the point, it's more that they're able to talk about what's going on, have good instincts, etc. If you're an experienced engineer, you've seen lots of people write code, you know what looks like "junior" or "senior" and "guy who thinks anyone can just pick up coding."

"But if I work on a computer I can compile and see the edge cases."

Are you interviewing the candidate or the compiler? Again, this is the ritualistic view of interviewing.

"But at work I have plenty of time to work on things."

Everyone has this problem, so everyone is less able to perform, and the interviewer can simply adjust expectations.

"All of these interviewing "tools" (or tricks) attempt to be time/cost efficient proxies for doing the damn job..."

That's very much the ritualistic view. Other industries have had notions of apprenticeships and so forth for thousands of years, and our problem is that we view recruiting, professional development, etc. as things someone else does, rather than something we take ownership of. Interviewing is a critical business function, it can produce value and thus is not a waste of time. If you treat it as a useless ritual, though, it will be.