Take a few minutes upfront to determine your time committment to studying for your interview. Adapt your plan to what you're willing to put in. You want to make sure you get a well rounded exposure to each aspect of the interview and not just overdose on algorithm practice.
Speaking of algorithm practice, this is probably the most important component of the process. A great resource is leetcode which has a list of hundreds of free algorithm challenges, all with in browser compiler / testers for the problem at hand. You get to choose your own inputs to test out your solution. Once you're satisfied, you submit to the full battery of tests, which may find edge cases that you overlooked, just like a real interview. This site has a wide variety of questions, from list manipulations, graph and tree questions, number theory, and string questions. Other users have often posted solutions in the discussion section, and reading through their thought process can be illuminating. I find the medium difficulty problems are the ones that are most important. The easy questions can be too easy, but the hard questions are often too esoteric. You'd much prefer to know the tricks associated with a few dozen medium problems than a handful of hard ones. I sort by "acceptance rate" as well, and go with middling acceptance, around 50%.
Get your resume in order and be ready to speak about anything on it. Be sure you can talk intelligently on each and every point on the page. It sounds simple, but you'd be surprised. Conversely, have one or two pieces of experience that you want to talk about when prompted. Have an answer to the questions "What's the most interesting project you've worked on?", "What's a difficult bug you've come across, and how was it resolved?", and "What experience will inform your work here?". Practice the answer to these questions with a friend, they need not be technical, or at least, record yourself answering the questions. You might find it awkward to listen to your own voice, most of us do, but it can be quite helpful, you'll be a good critic of yourself.
Research the company you're interviewing for. See what's recently been in the media, and give your take, or ask your interviewer's take. Have an earnest answer to the question "Why here?", hopefully it's something with the culture that resonates with you, or the cause matters to you for some reason. A good question for peers or senior interviewers is "what challenges are you facing this week, how are you planning to solve it?". For the hiring manager, though, the killer question is "If you hire me, what would success look like for me six months down the road?". This gets the hiring manager visualizing you in the role, thinking of you in a successful position, and also literally telling you how to please the company.
Know the format of the interview. Ask your recruiter or hiring manager what the agenda is. There can be variation, and it's important to prepare for each component. Get to know the coding environment that you'll be in during the interview. coderpad is a common interface, and each have their own quirks. Autocomplete, tabbing, missing python 2 are all things you should know before the day of the interview. If you will be whiteboarding, try to practice in an environment as similar to that as you can. Pen and paper works for this as well.
Sometimes there is a technical assessment which is often facts about certain languages and interfaces. It often feels like trivia that can be easily googled, but that is usually not allowed in this portion. General familiarity with the stack can be helpful, but finding "cheat sheets" for the language is another good way to study for this portion of the interview.
All in all, there are a number of components of the interview, and being prepared for their structure and type goes a long way in success. Ask a few days before for as much information about the format, and be ready for it.