Instead of grinding LeetCode, learn mathematics, bro

Exactly, most of these leetcode problems are now done by AI / LLMs, so it's mostly a waste of time to do leetcode.

The low hanging fruit has been picked.

Why don't we put all that solving these unsolved mathematical problems instead of these already solved leetcode puzzles that have tweaked variation and that the employers don't even use themselves.

I disagree partially. With enough practice you will be good in leetcode, though if you knew also math it would probably be easier for you.

But as far as I am I don't believe there is any math in algorithms such as bubble sort.

Agreed. The ability to formulate code problems as math problems, particularly as linear algebra problems, is a vastly underrated skill. The ability to grind out an already-solved algorithm is vastly overrated.

I've seen otherwise good programmers write loops over elaborate data structures to deal with what are effectively composed matrix math operations. Unless you're in a language that has first-class arrays (APL, R, Matlab), it's not immediately obvious how all those unknowns could be plugged into a system of equations and solved in a single op.

In a sense, math is the exact opposite of leetcode. Math is theoretical but can be turned to great advantage by a skilled programmer. Leetcode is entirely concrete (memorizable, not grounded in any theory) yet pragmatically useless for solving novel engineering problems.

So I agree, we need more engineers who understand dot products and eigenvalues, not algorithmic code golfing.

That is assuming your company actually wants to hire engineers - I suspect the purpose of leetcode is specifically to weed out people who are likely to ask "Um why would I write this leetcode algorithm when I could solve it faster by multiplying two matrices in BLAS?". We wouldn't want our engineers to apply critical thinking now would we?

Looking at the history of challenging engineering programs, I'd say, "math helps, but is in itself insufficient". I think serious engineering takes way more than good math chops. And having a mathematical inclination or turn of mind doesn't automatically make someone an effective engineer.

PS: My point is, Engineering should be seen a serious discipline on its own, which draws from math, science, psychology, management and a dozen other fields. No single aspect (either math or leetcode) should be emphasized as a panacea to Engineering mastery. There's no shortcut.

What does grinding leetcode mean here?

The way you prepare is important. A focused approach yields more learning.

Math is typically taught in a focused approach that builds on itself.

Random leetcode grinding does not build on itself.

But non random leetcode grind where you focus on specific topics can yield an underlying intuition similar to the one you would gain from a math first background.

I would argue that in the vast majority of cases, this approach has a better ROI of your time.

Interviewers seeking to "expose you" with math tricks are probably not people you want to be working with.

I thought for coding you only needed to know how to add 1 to something

Leetcode is the modern form of slavery of the tech ecosystem. Sad to see kids grinding away hours of their lives doing this instead of writing fun, useful programs for themselves and society.

Leetcode is not a means to learning best practices or going deep on some topic. It is a means to passing algorithmic interviews. Almost no leetcode "practitioners" will ever encounter the type of problems that require novel algorithm development. That's because these interviews do not resemble real world challenges most companies face. They exist solely to separate those who prep from those who don't. It's an effective measure for the big tech companies who get thousands of resumes per day. For most other companies it's unoriginal cargo culting. But it's also the reality we live in, so Leetcode continues to exist. Learning mathematics gets you further away from the goal of getting a job and is not practical (despite being a technically correct notion).

When they hire you as a cashier at McDonalds, your math is useless. All you need is learn to ask "do you want fries with that?"

I'm going to give you all a bit of very real advice from a very senior engineer. The premise of this discussion is based on a fundamental misapprehension of what the job of a software engineer is about. The amount of time you get to spend finding fun optimal solutions to optimize individual operations is like, 0.001% of your career. Most senior engineers, even those without a background in advanced math, have an intuition for optimization patterns over years of solving problems, and often the reason something has not been optimized for speed is not because nobody knew how to do it, but because speed was not a requirement.

The sort of engineer who can define the requirements of a project and execute based on those requirements is much more valuable to me than a algorithmic prodigy. Seniority is not defined by the mathematical complexity of the problems you solve. Focus instead on design patterns and best practices, scalability and maintainability concerns, mentoring of more junior teammates and the buildout of tooling that helps ease the overhead of working with the codebases under your purview and the development, deployment and testing of that code.

I have limited time and need to careful about how I spend it. If I need to prepare for an interview, I'll solve interview problems. I don't need to be able to come up with original solutions which took exceptionally smart people a long time to develop.

Frankly, I think you've given horrendous advice. Not just bad, but completely counterproductive.