How to Rock an Algorithms Interview
FTA:<p><pre><code>    You should know these data structures inside and out.
    What are the insertion/deletion/lookup characteristics?
    (O(log n) for a balanced binary tree, for example.)
</code></pre>
How does one achieve this?  Not just being familiar with data structures and algorithms (I am), but being <i>fluent</i> in them, to the extent that you can produce the Big O complexity for different operations off the top of your head.<p>I didn't have a traditional CS education in college.  Maybe there's some kind of magic that happens in Algorithms [1-3]01 that permanently etches these characteristics into your brain.  But whatever it is, I missed out.<p>My main problem is that <i>I don't seem to need this information to do what I do</i>.  I work predominantly with server-side, interpreted languages, and I just <i>don't run into</i> the bottlenecks and performance problems that Big O-knowledge seems to mitigate.  Maybe I've been lucky.  Maybe it's because none of my personal projects have gotten popular enough to be subjected to the kind of load that reveals such problems.  Maybe it's because I haven't worked on the <i>kind</i> of project that needs this sort of attention.  Whatever the reason, I simply have never hit a point in my work (which I assure you has been non-trivial at times) when I sat back and said to myself, "Gosh, if only I were more familiar with the complexity breakdown of the classic data structures, I would be able to solve this problem much more effectively or efficiently."<p>The thing is, I know that I'm perfectly capable of nurturing greater fluency in algorithms, so it seems like a waste to inevitably flub the more demanding portions of algorithm-based interviews.  So what should I do?  Is the answer as simple as biting the bullet and using flash cards until I know it all by rote (which feels like cheating), or am I "doing it wrong" somehow?  Is my lack of fluency preventing me from understanding just how important it is (<i>a la</i> Dunning-Kruger)?