One strategy that was on my mind today: Whenever you're writing an API start on the "consumer" side. If you had the perfect version of this interface, what would the code that's using it look like? I find that if I start on the "implementation" side I'm more likely to come up with a solution that closely reflects what was easiest/most direct to implement, whereas starting thinking from the perspective of the user of the interface tends to lead me to better abstractions.

I love this technique.

You can also use it when writing a block of code where you haven't decided what kind of functional abstractions or data structures you want. Write the code you wish you could write. Then fill in the code needed to support that.

This is 100% my coding strategy in every context where it makes sense. Code to an imagined ideal API that makes what I'm currently writing clear and concise. Once I have that written, I just repeat the process from the next level of abstraction down. This strategy has served me well over the years.

I like having static analysis for undefined names in my IDE for exactly this reason: I can write the program in the natural order (high level to low level), and then have a little reminder about what I haven't finished yet.

This is a great technique. I find it particularly useful if I'm stuck on writing some aspect of the implementation that I can't quite grok. Often pulling back and writing it from the point of view of a consumer of the implementation will help get me moving again on thinking about the problem.

One important aspect of leetcode/coding contest problems is that they have a input size constraint and a time limit constraint.

You can use the two to figure out what is the time complexity for a solution that would work. This simplifies the search for a solution by quite a bit. Here's a blog post about this idea (going from the input constraint to the possible algorithm): https://www.infoarena.ro/blog/numbers-everyone-should-know

Other than that, understanding a set of frequent data structures and algorithms helps a ton. Here's a short course from stanford on preparing for coding contests http://web.stanford.edu/class/cs97si/

https://codeforces.com/blog/entry/20548 is old but pretty good. for e.g. #2 is specific cases: "you get a problem for a tree. Consider its variant where the tree degenerates into a path".

came here to ask the same thing! :D

"How to solve it" [1] was helpful for me in this regard, but it isn't really condensed like this blog post.

After you finish "how to solve it", you can read the more advanced "Mathematics and Plausible Reasoning" [2]

[1] https://www.amazon.com/How-Solve-Mathematical-Princeton-Scie... [2] https://www.amazon.com/Mathematics-Plausible-Reasoning-Two-V...

Leetcode starts with an examination of the structure of the problem - the data structures present, the best possible time complexity. Knowing both allows a ton of narrowing down of the method that should be used.

Check out "An Algorithm for Passing Programming Interviews":

https://malisper.me/an-algorithm-for-passing-programming-int...

of course, it's important (for better or worse) to just grind out a representative sample until you understand most common patterns, e.g: https://seanprashad.com/leetcode-patterns/