[otabdeveloper2]

> This is clearly a useless skill as a software engineers except in getting a job at companies that do whiteboard interviews.

Have you ever actually been on the interviewer end of the process?

Literally over half of the candidates literally don't know how to program! They can sort of string together a Markov-chain something if you sit them down in front of an IDE and let them copy-paste stuff until syntactic errors go away, but put them at a whiteboard and they don't know where the parentheses go in a function call.

(They'll write crap like "()f" or "f()a" when they want to call a function, stuff like that.)

[int_19h]

I have been on the other end of the process more than once, in different companies and countries, and I have literally never seen anything like that.

[retiredcoder]

Me neither. Quite common deal breaker I seen is mismatch of expectations (e.g.: candidates applying for senior positions with experience to lead bigger projects, etc) but never seen gross incompetence like that (so that I am not even sure if GP is being literal or not).

[ereyes01]

> (They'll write crap like "()f" or "f()a" when they want to call a function, stuff like that.)

Who cares? If they write code that's well engineered and works in your product and they rely on auto-complete or whatever, isn't that what your business needs and why they really pay you? Furthermore, said code will be written from a comfy chair while they listen to their favorite music, with access to Google, SO, etc. And they will have enough time to leisurely think about what they're doing, test, refactor, etc.

In contrast, during such an interview, they are hand-writing code under duress for a problem they've had no time to think about while being judged by one or more people staring at them. If you're company is one of those famous ones where they get so many applicants they need to weed out many potentially good people, and also don't care whether they let in crappy people who game this system, then fine, whatever works.

[travbrack]

I think the function syntax thing is one of those things that's so basic that someone who gets that wrong probably doesn't code very much.

[ereyes01]

If you put someone in a fight vs. flight situation, and add in the task saturation of the coding interview, a competent person can react adversely and make basic mistakes. A week ago in a conference, I watched an SRE who I knew was very competent have a panic attack when a demo didn't work as expected. I never learned what exactly happened, but apparently it was simple enough that a colleague was able to quickly fix the problem over their shoulder.

Unless you're giving public demos/performances (which is what an interview is), this skill set isn't nearly the most relevant one for the job.

EDIT: This is a fascinating analysis of this phenomenon from a pilot's perspective: https://youtu.be/BBpqvPujZgM?t=1135

The video is the post-mortem of a plane crash at an air show with the pilot involved. In the part I linked to, he talks about the psychology of a skilled person when put under this kind of pressure and how the quality of their decision making can quickly break down. The whole video is also great if you're interested in aviation.

[retiredcoder]

Quite interesting.

Unfortunately, it seems that we are just now starting to realize the human aspects of software eng. Still, even if there could be a massive amount of data to show in which interviews, or more generically, how human judging or predicting personalities/traits/etc are intrinsically flawed

[oblio]

To make it worse it's actually fight or flight or freeze and freeze is actually the most common reaction...

[mk89]

I frankly still don't understand what's the expectation of such whiteboard exercises. It's just one method, and companies have to understand that one day maybe it will be superseded, hopefully soon. This "we have always done it that way" is ridiculous. If you want to know how good a candidate is, you can easily do it with pertinent questions and maybe a couple of pair programming exercises to see how the person codes, how he/she structures the code in a comfortable situation, not under stress and in an unrealistic scenario -> coding on a whiteboard, as if we had no electricity. Whiteboards should be a tool, not the goal of an interview.