Leetcode taught me that the vast majority of engineering problems are rote, and to think of the algorithms and data structures as the primary "Legos" (building

Leetcode taught me that the vast majority of engineering problems are rote, and to think of the algorithms and data structures as the primary "Legos" (building blocks) of each task. Besides understanding the algorithms that best represent the problem, the only hard task really is understanding what the customer is trying to accomplish via the proxy of a Product person. To me the really interesting part of engineering is educating Product people and customers about what computers are best suited to do and to rethink problems in systems of cheap tasks less than trying to fit arbitrary human centric processes (ie, a process that works for humans, but maybe isn't the best fit for a computer). Once we have a really clear agreement of the goal, it then fun to find a way to optimize a computer doing it. A really simple analogy might be long division[1] -- if you implemented the long division algorithm on a computer you'd waste a ton of LoC, when you (usually, w/ certain caveats) can usually just use a division instruction. Sounds trite, but you'd be surprised how often I see product people, and even "Senior" engineers, just blindly copying a 10 to 100 step algorithm because that's how the humans do it, missing that the problem can be decomposed to a few general patterns and then iterated, recursed, map/reduced, faster when batched etc. Often times these simpler computer centric algorithms also lead to much simpler code (for each do something simple), vs human centric algorithms often lead to big if/ifelse/else trees or code that does all of the tasks iteratively instead all of _one_ task for all items. [1]: https://en.wikipedia.org/wiki/Long_division https://en.wikipedia.org/wiki/Long_division