There's no need to struggle with them. You'll cover fully half of them simply with experience with trees. Build them. Traverse them top-down. Then bottom-up. Search it, Balance it, then rebalance on modification. Invert it, prune it, Roundtrip it to JSON, etc.
After mastering that, given a problem of "develop a flood-fill algorithm to this specification" should be a walk in the park.
1. To handle trees easily you have to understand recursion. Somebody with no CS experience (and no parser experience) might never ever used recursion in anger, even if they launched zillion commercial projects.
2. No Big-O notation. Interviewers usually ask questions about time/space complexity.
And the elephant in the room is that leetcodes are getting trickier and trickier, that's LLM era for you.
> 1. To handle trees easily you have to understand recursion.
Well that's the point of the exercises I suggest - to learn recursion :-/
> No Big-O notation. Interviewers usually ask questions about time/space complexity
Well, that's the other half of the interview, I only promised that my method will cover half the questions :-)
Then we must have been talking past each other. We are considering this problem here:
>> I never took affinity to computer science/math, but I love building real world products with software. [...] I am struggling with all the interviews that have these leetcode problems.
Then your advice to these interview problem is to learn some CS - the useful parts of it? E.g. recursion is CS.
> Then your advice to these interview problem is to learn some CS - the useful parts of it?
Theory was not my advice.
My advice was to do practical things with trees; I felt it would fit his love of building real things.
I mean, I didn't recommend doing problems out of a textbook, did I?
It sounds like leetcode problems require either memorization of a significant number of algorithm design patterns or seriously sharp algorithmic problem solving skills.