Their point is that just because someone can do leetcode does not mean they can program well, and they may too just be faking it to get a job they aren't qualified for.
After all, I learned chemistry, physics, math, mechanics, thermodynamics, etc., by working problem sets.
requires way more time, way more examples, way more code written.
I believe that in order to be "somewhat decent" at leetcode (not top level competitor)
you just need to learn theory, techniques, tricks and get some practice.
Meanwhile in order to get better at system modeling you need to model a lot of systems from scratch, change them and see how your initial design supported that refactor part
You need to be aware of various approaches / architectures, yada yada
And generally spend a lot of time thinking about how it'll affect readability or easiness to get into the project for new ppl, scalability, extensibility, etc.
So, in generally I believe that leetcode is just learn theory, practice everything you learned and go ahead and do 50 / 100 tasks
If you fail, then you can check answers and learn from them
meanwhile there are no correct answers for system modeling.
Additionally for leetcode you have sets with tasks to practice, meanwhile the "real" system modeling experience comes from real projects where requirements are being thrown and changed by somebody else whenever he/she wants
____________
>I don't know how one can study leetcode and fail to learn to program better.
I don't see how even hundreds of hours on leetcode would make you better at OOP, system modeling, building abstractions.
Because you know the foundations.
Knowing how a compiler works all the way down makes me a better programmer. Knowing assembler makes me a better high level language programmer. Knowing in detail how a car works makes me a better driver. Knowing how electricity works at the low level prevented a very costly mistake by the electrician who was wiring it (he had no idea). Knowing chemistry prevented a very costly mistake by the roofer of my house.
I'm thinking that
1) getting good at algorithms takes less time, than getting good at system modeling. — One will see one's mistakes sooner, within minutes, compared to system modeling, in which case one would need to stay at a workplace for months or years, to see how a system design eventually turned out to be a mistake?
But 2) it's also harder to get good at hard algorithm questions — most people won't get that good at it, also with weeks and months of practice. And they still wouldn't have any real chance in a Google coding interview.
And in that way, algorithm questions make sense?
They give more information about the person's ability to think and learn — good for the company —
and takes less time for the candidate to get good at (weeks or months — compared to working for years?), good for the candidate?
(I'm someone else than GP)
PS. I wonder what the electrician was up to? :- ) and the other one
LC can help you program "better" -- but in a narrow, "just tell me what I need to know to pass the friggen' test" sense.
To learn how to really program better - you'll have to start building things. And reading books. Meaning, you know, "hard" books. Not books about how to get past the LC barrier. And these things known as "papers", and man pages, and specifications, and the raw source code as written by people much, much better than you (even though 99.99 percent of it has nothing to do with LC problems). And by getting down there, in the trenches, and working with people who are plainly better than you are, and who you can almost barely keep up with.
That's how you get to be better. Not by ... studying to pass the test.