> How much time do you invest in reviewing algorithms that you haven't used in a while?
None. I don't want to work at companies that only hire people who memorized Red-Black trees.
If you don't remember, just say so. Try to reason about it, stating what you do know and can calculate on the back of an envelope. (I know quicksort is faster than N^2). You don't even need a google search to look up the details on an algorithm. Knowing when to use what algorithm is far more important.
In other words, it's just like they said in school: Show your work. Tell us how you arrived at your answer. Tell us how confident you are in the answer.
If you do want to practice, open a (non-highlighting) text editor and code something trivial. See if you can get it to compile on the first time. Repeat with other small problems. (This is how we did it in the old days.)
> What are the best prep resources?
Your stories. Passion projects you've completed. Interesting debugging techniques. What you did when the answer was not in the documentation.
Note: This is all just from personal experience in interviews. I'm not an interviewer, I'm an interviewee.
The fact you have an interview in the first place is a good sign - your résumé showed that you have the skills they need. A lot of the time, an interview is used to determine if you're a good fit socially. As for whiteboard coding, it's just used to show your thinking. Even if you screw it up, as long as you can explain what your thought process was they won't mind.
Anyways, I find the best thing you can do is research the company, come up with a few good questions, and tell the interviewer how it would be great to work with them. If they hit you with a curveball during the interview code test, you probably wouldn't want to work there anyways.
They have to like you, focus on that. I've been on interviews where I am very technically qualified, but the interviewers didn't care for my personality. This is one area that I am working on. Someone posted the following article which explains a lot of this: http://www.nytimes.com/2015/05/31/opinion/sunday/guess-who-d...
What I tell people is not to worry about their specific tech knowledge -- that should be something that you have more naturally.
The biggest issue I see is not being able to be coherent in explaining a tech project or concept. I would practice succint answers to technical questions.
In addition, if you are not comfortable coding in front of someone and explaining as you go, practice it with friends in mock interviews.
So no one feels that stuff like "Cracking the Coding Interview" is really that helpful?
Practice by interviewing with a few companies you don't really care about getting an offer from.
Disassemble their products and research whatever tech they used to build them for strengths & weaknesses.
Dig up whatever background info you can on the people who will be interviewing you.
They vary so much by company there's nothing really in common that you can focus on to prep. I've been on a few interviews where I actually wrote code.
As someone with horrible social anxiety that can barely talk without stuttering when under pressure I typically have a few shots of whiskey.