Also it's funny that engineers leaving Google, Amazon, et all NEED to practice these skills in order to get other roles because it just shows that these skills aren't needed (read: exercised, grown) working in their day-to-day jobs.
I'm not sure that logic alone is a compelling: It's conceivable that this secondary industry addresses a real gap in university curricula, or a need for ongoing training of experienced developers.
But I think your overall point still holds, because there's a consensus that a large number of Leetcode-like puzzles require familiarity with problems and solutions that hardly every come up in real professional software development, and aren't even good proxies for the abilities that do matter.
Wrong about what? That they are easy? If you know binary search, sorting, sets, hash tables, recursion then it is easy. If you wanted to make it more aligned with what a developer does day to day the alternative is doing a small project in your own time which is more time consuming for everyone.
But, then there's the ones that are all about specific techniques such as dynamic programming + memoization, or specific graph algorithms etc, etc. Any decent programmer can learn how to do these harder problems under time pressure (interview) through practice, but this is really about Leetcode grinding prep... these are not problems you would likely encounter in most jobs, and in the real world you'd just Google for algorithms or ask a colleague if you needed help.
As a senior developer currently looking for work, I have mixed feelings about leetcode-like questions. Here's my take:
Pro: They rule out most/all applicants who lack basic programming competence.
Con: Any timed or live programming test can make some applicants fail because of performance anxiety.
Pro/con: Some of the problems require (a) very high intelligence or (b) familiarity with how people have solved that specific problem in the past.
I think (b) is a major source of complaints, because for most people the only solution is Leetcode grinding, which outside of the interview process isn't a good use of one's professional development time.
Con: At least for timed problems on Hackerrank, you have a dilemma: A simple, straightforward solution takes little time to code, and is easy to explain. But it might also take too long to run on some of the test cases, which then requires you to guess at the source of slowness, and try to fix it.
But in multi-problem Hackerrank tests, you don't necessarily know if you have enough time to do that, because the other problems in the set might or might not require lots of time as well. And you can't revisit an earlier problem once you've submitted a solution.
But I’ll give Google a bit more credit than you and guess that they ask questions that are at least above the “easy” level.
Just take a look at the list https://leetcode.com/problem-list/top-google-questions/