One thing that helped me was to actually implement things that made use of the "algorithm stuff." Not just practicing in front of a whiteboard, but real executable code!
In particular, anything involving a Tree was never very intuitive until I tried implementing a script to search for files by name. Suddenly both the recursive and the iterative approaches made sense. I understood the trade-offs because they applied directly to my work. That opened the door for more complex algorithms, like a Huffman Coder (which I wrote in C, as part of a CS class).
The other thing that helps me in interviews is to just talk through everything I am thinking. It feels like I'm stating the obvious over and over, but a good interviewer will be able to follow your thought patterns and help you along when you get stuck. Also it just helps to hear yourself say things outloud sometimes. If you just stand there silently decoding a problem in your head, the interviewer can't help you and has no idea how you'd approach a real problem on the job.
> actually implement things that made use of the "algorithm stuff."
Part of the problem is that the overlap between "concepts used in technical interviews" and "practical things I would actually implement" is very small. So to take your approach, I'd have to go out of my way to implement something that, in the end, would have no utility to me.
Granted, there are developers out there who do take on really technical projects for fun. It seems like every language has at least one implementation of the GNU `coreutils`, which I'm sure requires at least some algorithm expertise. And there are, of course, jobs where the technical is really important (systems-level, research divisions, etc).
But for the most part, the types of interview questions they ask in no way correspond to the actual on-the-job requirements. I find it strange how common it is to interview web developers (or, engineers whose job will effectively be web development) as if they are C programmers.
> The other thing that helps me in interviews is to just talk through everything I am thinking. ... If you just stand there silently decoding a problem in your head, the interviewer can't help you and has no idea how you'd approach a real problem on the job.
This.
Most important thing for me as an interviewer is for you to talk out loud about what you're doing and what you're thinking.
Just let it flow - all of it.
Programming is often a solitary thing - we go through a lot in our own heads when writing code; e.g. say I ask you to write some code to iterate through some website log files and build a site-map from the URL paths in the log entries. I bet that your mind - even as just a reader of this comment - has already started working out some of the steps to do this ... "load the files, iterate through line by line, some sort of map or DB to store the files, some way to handle duplciates" etc. You might even already have some questions lined up about number of files, frequency of running, shell-scripts vs "real" code etc. Great - but I need to know that you thought about that stuff and I wont unless you talk about it out loud.
Standing silently at the board is not giving me the interviewer as much to go on. Even if you get stuck and/or make a mess of it and dont have a working solution at the end, if you've talked out loud about what you're doing, why you're doing it (and why you're NOT doing something else etc) might be enough on its own to get you pass that interview despite your solution not working (everyone has off days, but show me your thoughts!)
In particular, anything involving a Tree was never very intuitive until I tried implementing a script to search for files by name. Suddenly both the recursive and the iterative approaches made sense. I understood the trade-offs because they applied directly to my work. That opened the door for more complex algorithms, like a Huffman Coder (which I wrote in C, as part of a CS class).
The other thing that helps me in interviews is to just talk through everything I am thinking. It feels like I'm stating the obvious over and over, but a good interviewer will be able to follow your thought patterns and help you along when you get stuck. Also it just helps to hear yourself say things outloud sometimes. If you just stand there silently decoding a problem in your head, the interviewer can't help you and has no idea how you'd approach a real problem on the job.