Re-visit the ones you got wrong first. Try them again, repeat until you've gotten them all right (this might just be because you remember the solution from looking it up, that's fine, you'll have plenty of time to forget by the time we get back to it :).
Now, revisit the ones where you had the right data structure on the first go. HOW would that data structure help? Go a level deeper on actually trying to solve it.
I can't guarantee this will be fun, but it should be fast. A few minutes here on there on any given problem, going one level deeper each time you visit it.
Eventually you'll have the whole algorithm for one of the problems, likely using some common data structure like a hash map, tree, or heap.
Code it in a language with a good set of algorithmic primitives, use every tool the library gives you (don't worry about remembering how the data structures work on this pass). Hopefully with the whole algorithm in mind and all of the tools at your disposal, this is "just plumbing".
Rinse, repeat.
Somewhere in there, do the same with the complexity analysis (time and space!).
Next time, try it where you have to build the data structure by hand.
Then one day you'll see a problem not on your original list, and you'll immediately think "red-black tree with a hash table lookaside buffer, but I wouldn't want to have to build the RB tree by hand if they asked me to, so AVL tree because the complexity is the same and I can bang out the code like it's what I do every morning before breakfast".
Like I said, it might not be fun (at least at first), but it is a way to break up the practice into digestible chunks. Also it builds on the strategy that I've seen work best in interviews -- if you treat each step of iterative deepening of the solution as a point where you'd talk with the interviewer about what you're thinking and why, you give them a lot to go on about your thought process and a chance to course correct if you misunderstood the question or your heuristic for how to approach it simply came up wrong.
I'd recommend that you only solve problems that are extremely easy, on websites like https://www.spoj.com or https://www.topcoder.com or old google code jam questions. Pick a single website (I recommend codejam) and do only the easy ones for a few months. It's hard to argue against the happiness that comes when your program passes the tests. The point is not to sharpen your skill but to get used to the feeling that your program passes ALL the tests cases.
If you get to a stage where you're completely sick and bored of easy problems, pick a slightly more difficult problem with basic algorithms like plain BFS or DFS. Try it for just a day or two and when you can't solve it, read the published solution. Try to understand it, apply it manually to the test cases and once you're sure that you've completely grasped the solution, implement it and see if it passes all the tests cases. Take it slowly, and return to easy problems often.
This could take you pretty far in terms of enjoying the process. :) At least that's how it worked with me -- I liked the high of getting a program "accepted".
My approach is to keep writing the basic algorithm, data structure, common questions again and again. Do it once every 2-3 weeks. When I know every part of them, then I can start twisting or go deeper.
I am not that top talent. Sometimes even a 0-based or 1-based array can bug me a while.