1. Everybody agrees interviews and tests have some signal, some noise.
2. Some interviews are systematically biased toward skills that aren't a good sample of what work is. But people just want to whine about it rather than propose a better solution.
3. Nobody can agree on what the important skills are for engineering anyways. Which is natural, since it varies situationally.
Likeliest scenario people say a bunch of vague phrases like "communication skill" and "culture fit" and "diligence" at each other, forget they had this conversation, and thread continues to happen every 2 weeks for the next 10 years (I guarantee this conversation has happened no less than 100 times here already).
Hypothetically not-meaningless form of collaboration that would never happen on HN -- people form a google doc and come up with concrete questions that they upvote/downvote to come up with a great engineering interview, and each new discussion adds to the list.
The main contention developers seem to have (in my mind) isn't necessarily all whiteboarding interviews. Its the ones with ridiculous problem complexity and timelimits of under an hour that require inordinate amounts of study every time someone begins their job search (Dynamic programming in 45 min comes to mind). I think there are plenty of good alternatives in this thread: take-home assignments, paying developers to study and take these exams, github code reviews, even just restricting the problem space of a whiteboard interview to less complicated problems are all good suggestions.
The other point I was trying to make was that generally the skills you want to test for in an interview are those applicable to the job. Others in this thread have argued that these whiteboarding problems do in fact test some important subset of the skills needed by most developers. Others have pointed out that at some point though, its gotten ridiculous, and knowing how to sort and array in O(nlogn) is not really applicable to all the jobs interviewing for that knowledge, and it would be a better use of everybody's time to instead test for some other subset of knowledge (SQL use, CRUD application construction, etc.)
Finally I just wanted to point out I am an interviewer at my current company. I do take a lot of these conversations to heart. I have tried to experiment with the interviews I give to make them better for the candidate, and better for the company. Anyways, just pointing out I do think these conversations have an impact :)