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.

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.

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!)

There is a huge amount of randomness in interviews. I usually say this as a bad thing, but in your situation now, it can actually be a good thing. Interviewers look for a WIDE variety of traits. Most ask algorithmic questions. But if you do enough interviews, you will find a company that values the skills that you have (I am assuming here that you can program productively). Smaller companies particularly have more variance in what they are looking for. I encourage you to just treat this as a numbers game, and get applications out to as many small and medium companies as you can.

This sucks. But it can and does get better. After you have a few years of experience under your belt, companies will look at you in a very different light.

EDIT:

Also want to add that we made Triplebyte to help people like you. We'd love to have you apply.

There is a real need for people who understand programming, even if they aren't heads-down, programming geniuses themselves.

I've been in almost a dozen programming interviews and maybe only 1/3 of them have taken the shape of programming whiteboard problems.

Many just asked general technical questions or questions about my particular stack with no whiteboard problems.

The remainder of them hardly asked any technical questions at all beyond asking about my experience and background.

I'm not saying that those companies gave good interviews, but there is a lot of work out there for people who can't pass whiteboard interviews.

If you do want to work as a professional programmer, try just typing through solutions and understanding them. After lots of exposure, you'll start picking up patterns. Dynamic programming and greedy algorithms are taught so quickly that I'm surprised students generate intuition for them! Feel free to get in touch if you're struggling. Best of luck.

System design, user interface design, HCI, software engineering (methodologies, management, architecture), infrastructure, etc that don't lean as heavily on the algorithmic side of CS as they do other aspects.

I know that while interviewing where I work, a candidate's attitude and enthusiasm for programming are much more important to me than their ability to solve some riddle in half an hour. It's not the solution I'm looking for, it's how they get there.