Instead of grinding LeetCode, learn mathematics, bro

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've done over a hundred interviews now. One of the most valuable engineers I hired had an interview that steered off course from the original algorithm question I had in mind. I opened with a "what's the most challenging part of your job currently?" and he responded "Upgrading our monolith front-end from Angular 1 to Angular 2".

We spent the entire hour discussing back and forth all of the challenges not just for him but the team in great detail and how they went about doing the upgrade. I'm glad the interview didn't go as planned because he's still here and he's great.

This is how I mostly do interviews. Get the candidate talking about their previous roles and see how they talk about the problems they've solved and what that reveals about how they see the job.

I personally would make something like this the default interview approach for anything but entry level positions.

Yep, I love doing interviews this way - we just talk shop. It shows way more about the candidate than any abstract problem I could devise.

Doing leetcode in interviews is like if the NBA drafted players based on trick shots.

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.

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).

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.

Because it seems we have agreed that we need an arbitrary way to curtail the demand to some of the highest paying jobs on the planet, rather than an actual methodology around proving requisite skills for said jobs.

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.

> instead of writing fun, useful programs for themselves and society.

What people don't understand is they'll have a higher chance of getting hired if they do this.

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.

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

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?"

Since when did McDonalds start conducting LeetCode interviews for hiring cashiers?

It's a metaphor. McDonald's business is fries, as software houses jobs is software. Math is entirely incidental to those, effectively don't matter.

If you wanna get (and keep) a developer job, learn development. Leetcode is just an example, learn algorithms and data structures and patterns and languages. Math is literally the least useful thing to learn in 99.98% of real programming jobs.

> All you need is learn to ask "do you want fries with that?"

This skill isn't needed anymore because fries are included in most meals.

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.

Sorting itself is a mathematical operation. It's part of set theory, specifically order theory. The entire algorithm is a mathematical expression.

I really want this general concept to be true from a “practicality sense” but am having trouble seeing it.

Expressed as a mathematical expression. Given a problem that arrives at timsort with galloping mode as the solution, how would you hear the initial problem, and then express the solution as timsort in order theory?

It feels like it would be awesome to do but also doesn’t feel like the logic of the algorithm would quickly be found simply by knowing order theory.