There's still quite a lot of signal for an interviewer in someone being ready to do the extra work to achieve the goal (e.g. study for interview) vs. someone how doesn't want to invest time into studying and just wants to throw stuff together. This is especially important for junior developers (since as a company you'll want to train them up long-term to be promoted into higher level), but still remains important for senior developers (since being stuck with someone who refuses to learn new skills is a long-term problem for the company).
There's still quite a lot of signal for an interviewer in someone being ready to do the extra work to achieve the goal (e.g. write a real application) vs. someone how doesn't want to invest time into writing a real application and just wants to play with little algorithms and exercises.
Now if you smell a straw man or false dichotomy (hint: writing software instead of cramming leetcode doesn't mean you're not learning new skills; and vice versa) in this, you're on the right track.
The other thing is, what exactly is this signal? What does it tell the interviewer? They have their prejudice, so the signal tells them what they want to hear.
Maybe the actual signal is "I'm bored and desperate and don't have real skills and can't think of anything creative to do so I'll just cram leetcode until some unfortunate company thinks I'm leet and hires me. Because someone on the internet told me that's how you get a job."
This is why I'm not very keen to hand wave about "signal" if there's no way to give it an unambiguous interpretation. In these hiring discussions, I've seen so many examples of "signal" that can be interpreted any number of ways but someone thought they came up with a clever interviewing method so their interpretation of the signal must be right... right?
If it's a hazing ritual and lots of jumping through hoops, the only signal you have is that a person is willing to go through a hazing ritual and jump through hoops. Don't assume anything else. In particular, don't assume it says anything about the skills or capabilities of those who are not willing to go through it.
However, you will stand out if you ask “why did you choose those questions?” Or “how did you come up with those problems?”
Even the best interview that fits in all the check boxes trumps a similar candidate who shows they give a shit.
(Disclosure: We did this at a company I worked at).
First, I actually believe white boarding questions (at least the automated kind) are assigned more indiscriminately than take home assignments. Many companies just send you online timed hackerrank or leetcode questions as a preliminary filter.
Second, the entire interview process rewards people who study for the interviews rather than those who like to build projects. Unfortunately I believe companies miss out on a lot of qualified candidates, albeit reducing their false-positives from obscure algorithm-type problems. With so many applicants, reducing false-positives ensures quality hires so it works on the company’s end.
Overall, my opinion is the interview process is relatively broken. Take-home assignments offer more insight into actual development skill, while whiteboard questions filter out a large portion of people (many who would be just as good, if not better, at actual implementations.) But it works for the interviewers so change seems unlikely. This is just my experience for new graduate interviews; perhaps it is different at higher levels.