It also doesn't hurt to simply practice programming problems and revisit old academic excercises.
Make some flash cards with datastructures on them and use them to try and recall as many of their useful properties as you can (eg: Binary Heap, binary tree with x constraints, O(n) search, O(log n) insert in worst case; etc).
The advice in the article about honestly answering, "I don't know," is key -- don't pretend to know. You'll get called out and blow the interview. Instead, explain what you do know and think out loud when you walk through the problem with them (or how you'd go about solving it).
One way I've practiced "thinking out loud" is to get a white board and pretend you're a professor. Try to explain the solution to some problem you are familiar with in layman's terms to your pretend audience -- but do it out loud. Then find a problem online that you're not familiar with and do the same thing. Pretend you're a professor or engineer or some sort of brilliant person and walk through the problem with yourself -- out loud. Write diagrams on the board, explain your every step to your pretend audience, and really get into it. I found it helped me quite a bit and I frequently use the technique to walk through problems I'm not familiar with in my own studies.
> One way I've practiced "thinking out loud" is to get a white board and pretend you're a professor.
This.
I'd never done "whiteboard testing," and I still hate it, but a lot of people use it apparently. I remember the first time having to do it, and I was so focused on the white board, and having my back turned to the interviewer, and just the odd sensation of everything (not to mention very little sleep the night before) that I was drawing blanks on the most basic of questions.
Don't even get me started on the practice of writing code on the whiteboard. Who even does that in real life? By the time, a line of code I wrote on the board extends to the right, I forget what I have written on the left. Is it too hard to provide a fraking computer to type on?
I guess here's one advantage of trying to get a job coming out of academia: We do that kind of whiteboard discussions all the time. I'm actually surprised that you wouldn't have done this ever at a normal job either. I mean, how do you hash things out with your coworkers?
There is a big difference between hashing things out with coworkers and trying to write that will run without a typo. I have no problem using a white board, and throwing up examples, etc. But actually writing out variable declarations, assignments, etc?
Make some flash cards with datastructures on them and use them to try and recall as many of their useful properties as you can (eg: Binary Heap, binary tree with x constraints, O(n) search, O(log n) insert in worst case; etc).
The advice in the article about honestly answering, "I don't know," is key -- don't pretend to know. You'll get called out and blow the interview. Instead, explain what you do know and think out loud when you walk through the problem with them (or how you'd go about solving it).
One way I've practiced "thinking out loud" is to get a white board and pretend you're a professor. Try to explain the solution to some problem you are familiar with in layman's terms to your pretend audience -- but do it out loud. Then find a problem online that you're not familiar with and do the same thing. Pretend you're a professor or engineer or some sort of brilliant person and walk through the problem with yourself -- out loud. Write diagrams on the board, explain your every step to your pretend audience, and really get into it. I found it helped me quite a bit and I frequently use the technique to walk through problems I'm not familiar with in my own studies.