Personally, and for many people I know, cramming was not necessary because we had a conceptual understanding - maybe a week or two of doing 2-3 a day and you would be set.
Anything you do in an interview is going to be an artificial signaling value. I think LC is a much better signal than the talk-out-your-ass approach you seem to favor, and I've done both sorts of interviews.
The difference is also pretty obvious in the quality of your peers based on what sort of interviews your firm does.
Apologies for being pedantic about word use but that time commitment is longer than what's normally meant by cram. Traditionally a cram would be up to a day or two of hard work before exams. What you outlined would just be study (an even larger barrier).
> Anything you do in an interview is going to be an artificial signaling value. I think LC is a much better signal than the talk-out-your-ass approach you seem to favor, and I've done both sorts of interviews.
I prefer the talk out your ass approach personally, but maybe with a detour to asking the candidate to describe something technically challenging they worked on. If the interviewer is fast their your feet and the candidate is skilled at explaining then you can go reasonably deep. After this the interviewer can usually weigh the talk-out-your-ass claims accordingly.
> The difference is also pretty obvious in the quality of your peers based on what sort of interviews your firm does.
Our firm (fast growing series a startup) struggles with this, so take all of the above with a grain of salt. Our problems seem to be more related to not being able to generate a large enough talent pool, not with inaccuracies cherry picking candidates. We hire about ~25% of genuine applicants and find our main problems post hiring are if they are willing to take initiative and be self directed.
The point of leetcode isn't to find the best engineer, since that's not possible in one day of interviews. It's to find someone who has the thinking skills and is willing to put in the time required to be a great engineer. Cramming being helpful is largely the point, companies want people who are committed to being the best.
If instead you surprise them with it in an interview, they can't do it, and you don't hire them because of it, well, they are the ones that dodged a bullet not you.
I know about third normal form because I learned it from my girlfriends open-on-the-ground textbook in college. It's just not that hard.
Same goes for Leetcode. Anyone can Google how to implement some algorithm, but you won't be told what algorithm to use in your project requirements.
Of course, an interview could just involve getting you to give general descriptions of things instead of implementing them, which would satisfy this to some degree. But then everyone with a bachelors would pass the interviews, so they had to make them more intensive in order to limit the pool further.
Likewise there are plenty of people who have learned database design through a combination of optimizing execution plans and dealing with the practicalities of schema changes. Such people may never have heard the term "Third Normal Form", but will run absolute rings around a college newbie who has. Indeed, in my career I have met at least two people responsible for database design who did know normal forms but did not know about execution plans, or covering indexes for that matter. Or had a nice normal set of tables, and then proceeded to build a reservation system (hit by 100,000+ users when registration opens) that takes a transactional lock on a single row using an ORM. They understood database theory from 1971, but they didn't know what this specific database implementation actually does.
This is the exact opposite of LeetCode. It proves they've crammed on the front-end of the long tail wave of problems. It shows absolutely nothing about recognizing general problem domains and being able to identify long term solutions.
You're right it has no long term importance. It's just a different, still artificial signaling value.