There's absolutely no way you should expect to be able to practice all possible questions.
It's not about memorizing anything, it's about having enough exposure to data structures and algorithms that you're able to figure it out, and quickly. And you get this exposure with practice.
Take some online data structure and algorithms courses (e.g. from Coursera - they're free) - I learnt so much from some of these courses, which were supposed to be undergrad, even though I already had my degree - the difference between different universities are so large that you absolutely need to take some of these courses to make sure you're up to scratch.
Spend some time on competitive programming sites (e.g. HackerRank, CodeChef,
There are plenty of blogs and such (e.g. CareerCup and GeeksforGeeks.com) about coding interview questions - don't read the solutions right away, write the actual working code on paper and time how long it takes you - your goal is say under an hour from when you start reading the question, as that's around how long interviews usually are.
Stack Overflow can certainly help, specifically the algorithm and data structures tags - you don't even have to answer anything (at first), you can just read the questions, try to figure it out yourself (try writing the code), and then read the answers. While many of the questions may not be interview questions, things like finding bugs in others' code will also do quite a bit to make you a better programmer.
Reading and writing understandable answers also helps a lot with making yourself better at explaining yourself well, which is very useful in an interview (don't post code-only answers).
In terms of generic interview tips - talk.
I realize some people may think better in silence, but the problem with not saying anything is that the interviewer has no idea what you're thinking. Walk through what you're planning to do. If you have some ideas, even if you think they're bad or won't work, just share them (you can even say you think they're bad - believe it or not, but bad ideas often help your chances, a lot).
If you don't say anything, and you're not writing anything, the interviewer will most likely ask you questions to determine whether you might need a tip or what exactly is going through your mind.
You should expect to respond to a question at any time though - they may ask for your motivation for making particular choices, or try to lead you in the right direction with some leading questions.
Keep in mind that a 'bad', really obvious, solution is better than no solution - for your example, even if you just write code to step through the linked-list, and insert the elements into the front of another linked-list, that would end up with a reversed list, that's way better than not giving a solution. If you're ever stuck, take two steps back and try to think of some really inefficient way to solve the problem - with interview questions, there often is one.
Also, don't make any assumptions - asking for clarification is good. Actively try to not start writing code straight away - try to find at least something in the question that is unclear that you can ask about. Right of the bat - what type of linked-list is it? Double or single? You can ask about time and space complexity, but I wouldn't be too concerned with that to start, as these can serve as major distractions to a somewhat worse solution that may still be considered acceptable and end up getting you the job.
In terms of practising actual interviews - get yourself a programmer friend to do a few actual practice interviews with you.
Get yourself a whiteboard (or a notepad might work too), have him/her ask you something like "reverse a linked-list" and write the actual code on the whiteboard. Have him/her:
- Check that you're asking for clarification
- Check that you're not quiet and doing nothing for too long (I'm not sure how long is too long, 30 seconds?)
- Randomly pop in with a question asking why you made a particular choice or ask you to explain your code
They could get their questions from a blog about coding interview questions, so you have no idea what's coming (it could be an intentionally underspecified question, so you need to ask for clarification (good), or make a ton of assumptions (bad)).
I'd mix in some non-coding (i.e. HR) interview questions too, as you're likely to get these in actual interviews, and answering these might require different mindsets, and you're trying to make it as close to real as possible.
In closing - practice writing fully working code without an IDE, without testing it before it's completely done (and then extensively testing it to make sure it works). If you're not used to going without all the help an IDE gives you, you could have a hard time with that aspect alone.