5 ms·
People who say they are bad at leetcode sound like the people who say they are bad at math. Sure, right now you might be worse at learning math than someone els
by Shindi 4y ago
People who say they are bad at leetcode sound like the people who say they are bad at math. Sure, right now you might be worse at learning math than someone else, but there are strategies to learning math better
If you are memorizing leetcode you are doing it wrong.
If you are doing more than 60-80 problems, and not applying to the most competitive companies, you are doing it wrong.
There is a strategy to learning how to study leetcode, and yes, studying leetcode is hard. But you need to make sure you are not blindly memorizing solutions or else you're doing it wrong and wasting time.
Let's say you are doing an array problem and there is some trick that is necessary for the problem that you didn't know. When you get the problem wrong, learn what the trick is, but don't "memorize" it. Learn it and learn how it works. Then think deeply on what other problems might use this trick. Does it involve a loop that goes until `i <= someVar.length` ? What happens if you change the code to < instead of <= ? What happens if some other edge case happens?
I've seen this happen with binary search. Someone learns the algorithm by finding the algorithm online in their language of choice, but doesn't spent time fiddling with the code or thinking about edge cases.
- andybak 4y agoMy feeling is that people who understand maintainability or other architectural concerns are worth more than people who master algorithmic underpinnings. I thought the point of this discussion was how to change the industry emphasis rather than how to get good at it.
- myth_drannon 4y agoHow can you test someone who can write a well maintained code? Architectural Concerns are tested during System Design round.
- mattlondon 4y agoCandidates who care about readable solutions, provide comments, add unit tests, think about integration testing, data validation, bootstrapping/deployment etc are the ones who are at least thinking about maintenance. Incomprehensible one-liner whizz-bang solutions in perl are great and all, but no one wants to work with someone writing code like that.
- billllll 4y agoHow do you understand maintainability and architectural concerns without understanding algorithmic underpinnings? At the base level, leetcode problems and maintaining a complex system in practice requires key understandings: what your problem is, which tool to use, and how your tool works/tradeoffs. It follows what (I hope is) a universal truth: if you want to be a good coder, you need to know code. If you want to change the emphasis, just don't work at companies that provide leetcode questions. If your hypothesis is true, then all the companies that don't do leetcode questions should have an advantage since their engineers are better at the practical aspects.
- andybak 4y ago> How do you understand maintainability and architectural concerns without understanding algorithmic underpinnings? > At the base level, leetcode problems and maintaining a complex system in practice requires key understandings: what your problem is, which tool to use, and how your tool works/tradeoffs. It follows what (I hope is) a universal truth: if you want to be a good coder, you need to know code. I don't buy this at all. Orthogonal things are orthogonal. I work with developers who probably have no idea what a red–black tree is but I'd trust them to advise on how to structure a complex project based on user requirements. I'd rather they spent their time getting better at the latter and I don't see how getting good at puzzles is especially helpful in doing that. Programming in the large is usually about managing complexity over time. It has more akin to designing a large factory than it is to understanding how a pocket watch works. There's a huge human factor as well - complexity arises where people meet code and understanding how to keep that complexity in check is the key to being a good programmer.
- ikrenji 4y agoyou learn math by doing lots of problems, the same is true for leetcode. sure there are patterns and tricks to it, but you have to do enough problems to apply them "intuitively". it's one thing to know you need two pointers to solve a problem, but a different thing to actually code up the solution...