Popular or not -- objectively speaking, this reflects a rather skewed sense of priorities.
I can think of a huge list of make-or-break attributes for a potential working environment - for example:
- Do they value code as craft (like really, at all?)
- Does their business make sense -- both from the money-making perspective and as something I can see myself contributing 70 percent of may waking hours to for many years on end?
- Are they... nice? Jerks? Ego cases? Is it possible to have a normal, adult conversation about whether X is a good idea (without it turning into arm wrestling or "it is because Y said so"-type discussions)?
- Down to finer points like actual working conditions, tooling, and a minimal degree of sanity with respect to time off + vacations.
In this context -- "Are they well-versed in the finer points of whiteboarding?" doesn't even remotely figure into that list.
Asking to come up with a recursive pathing algorithm for your custom tree implementation in c on a whiteboard when they are applying for a ruby job maybe not so much....
But using the whiteboard as an interview technique is a terrible idea. It's not representative of the work that the candidate would be doing, and it doesn't give the interviewer much in terms of useful information about the abilities of the candidate.
I have absolutely used whiteboards on the job at every software job I've had. Collaboratively brainstorming a system design, working through examples, and conceptual context shares all work much better in a whiteboard environment than pretty much any other environment that I know. I get that it's good to cater to introverts, but I don't think that means it's unreasonable to expect someone to present ideas and collaborate while on the job.
It's fine to criticize whiteboard coding as unrealistic, but the author is saying that whiteboard-based interviews as a whole are "social ignorance and intellectual dick-waving". (Technically they just used the term "whiteboarding" without defining it, but I think if they meant "whiteboard coding", the article needs to be more specific about that.)
Does this person ask good questions? Do they respond to my hints well? Do they give up easily?
During an on-site, I'm very much evaluating abstract and interpersonal skills. I'm evaluating how well they communicate, how well our personalities mesh when collaborating, and how well they solve our engineering problems. I'm not evaluating how well they can code; they've already been screened for that before the on-site, typically on a Coderpad in the comfort of their own home with whatever language, tools, and resources they prefer.