That's what people always say. Like, as if they actually tell from 1 or 2 of these goofy whiteboarding sessions.
It seems the most they can actually glean from these sessions is, "Huh, looks like their problem-solving approach is different from mine. Plus, they come in not having the advantage of having the solution already ready-baked and laid-out for them, in whatever interviewing guide it was I found this problem. Doesn't that suck for them? Not to mention being under pressure from doing way too many, generally carelessly orchestrated interview tracks (in their non-existent spare time) while being stuck in some job they're anxious to quit. And getting distracted by me diddling with my cell phone while they're doing headstands for me. Gosh, why is it so hard to find decent candidates, these days?"
When I mean "right approach", I mean that there are several possible approaches, but only one of them is doable in a few hours in the afternoons, where as the others might take a research team and several weeks. Being able to recognize the right approach, and to ask the right clarifying questions, is important for data scientists, in the same way that being able to choose the correct algorithm or data structure is important for (certain types of) software engineers.
What rubs me the wrong way is when, applying for more or less "standard dev" jobs, one gets asked research-grade questions (i.e. "Solve this cute problem I was fed the solution to recently, either in grad school or in some handout my manager gave me just now. But which was actually an open problem in the literature for 5-10 years before a reasonable solution came down the pipe.")
For a job that ends up being, "Congratulations on making it through our interview process! Now would you mind debugging this {{horribly written X}} that no on here wants to touch with a 10-foot pole? Everyone here has to do 9-12 months of shitwork before moving on to anything interesting here, you see."
For example, going through all the issues with the question and implicit underlying assumptions, talking about what you'd need to give a good answer, or the characteristics a good answer may have might not be exactly what the interviewer expected or was looking for - but such an answer could demonstrate your competence in the field and be a good answer.
On the other hand, trying to make up an answer, or brazen your way through with jargon while hoping the interviewer didn't notice would likely be a bad answer.
It's not that these companies are looking for a single kind of thought. On the contrary, I believe they value different kinds of thought. Instead, they believe they can sort kinds of thought into desirable and not.