[hueving]

Ugh, communicating with a whiteboard has no overlap with developing a solution to a completely unexpected quiz (if you didn't cheat) on a whiteboard in front of someone scrutinizing your every move with your future career on the line.

Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not.

If you defend whiteboard leetcode using this excuse you are deluding yourself and you are part of the problem. The only thing the modern FANG interview hires for is people that can solve algorithms problems in a silo under pressure. No checks for software engineering skills, collaboration skills, testing skills, reviewing skills, and on and on...

The whiteboard interview is why so many engineers unexpectedly suck.

[hvidgaard]

> Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not.

They you are asking the wrong questions. I use whiteboard for developers, and for junior developers I give them a simple task such as reverse an array, turn a string into a palindrome (and explain what it is if they don't know). If they want to be a developer they must be able to solve those simple tasks. I don't really care how, as long as they think loud. Then I use it as a starting point for enhancement discussions, perhaps stack/heap questions, recursion, assignments ect. During all this I coach them, teach unknown concepts in simple terms - this is what they can expect when they ask their mentor a question so in that sense they get a feel for us too.

Some argue that it's still not good, and that we're filtering out people that work best alone. That is true, but that is by design. We work as a team, having 10 individual developers not working together unless forced is an architectural nightmare.

[hueving]

If you think someone looking over your shoulder while you solve a problem with your future career on the line is anything like "working as a team", I weep for whatever work environment your developers work in.

[hvidgaard]

So a simple problem solved while communicating, asking for clarification, and telling your thoughts is "someone looking over your shoulder while you solve a problem"?

I'm not asking them to impelment van Emde Boas tree because I spend countless of hours implementing and analyzing it getting my degree. I ask them to turn a string into a palindrome, or return the sum of all even index in an array of ints, ect. They're free to ask all the questions they like. It's a litmus test to see if they know simple programming, akin to seeing if a contractor knows how to drive in a nail using a hammer.

Is it high pressure while your future career is on the line? Absolutely, but they are not special snowflakes, and it's the case for any interview for any kind of position. I'm not going to throw thousands of dollars after someone just to figure out that they have in fact never written a functioning for loop.

[dasil003]

Agree with most of what you said except the conclusion.

The reason many engineers unexpectedly suck is because it’s a high paying job where performance is difficult to measure let alone predict.

White boarding interviews are a symptom of the problem, not the cause of it.

[markatkinson]

I always thought it would be a good idea for the interviewee to also come up with a question and then have the interviewer try and solve it with their guidance. I imagine it may be more helpful than the other way around.

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.