It's incredibly difficult, honestly. You're gonna have to prioritize which projects are important to you and cut corners/make sacrifices to dedicate a very sma

It's incredibly difficult, honestly. You're gonna have to prioritize which projects are important to you and cut corners/make sacrifices to dedicate a very small amount of time to them. By "cutting corners," I mean things like settling for lower test coverage than you're comfortable with, hacky CI (if you do CI), more tightly-coupled code than your happy with; i.e. all of the things that startups do to ship stuff fast. As for leetcode, I'd recommend doing that during downtime at work (if you can) and focusing on one problem a day, especially given your years of experience. Many of the medium/hard problems are basically puzzles; you either have that kind of mind or you don't. In my opinion, this is why side projects matter way more: you can bullshit Leetcode problems (by memorization), but you can't bullshit _things that actually fucking work_. (#338, "Counting Bits", is a great example. The trivial solution is O(n) time, but getting to the O(log n) time solution requires you to think about the pattern in which the 1's in the bit sequence typically generate. I would've never thought of that had I not read the solution.) Like some other posters have said, you'd be much better off (re)learning foundational data structures and algorithms and, if you can, implementing them from scratch. No, you'll never actually implement a hashtable library or quicksort, but knowing how to do those things will help when you get asked a leetcode-like question. Good luck!