Pretty much all of what's covered here should be part of a good Algorithm class. My own instinct (and a careful reading of the itemized list in that repo) tell

Pretty much all of what's covered here should be part of a good Algorithm class. My own instinct (and a careful reading of the itemized list in that repo) tells me you're fudging there - and more than a tad bit. And that's precisely the point - coding interview have become like russian roulette. A decent chunk of the material is basically trivial, some of it borderline... but a steady portion of it just isn't, and (not too often - but far too often) outlandlishly so. As in, not impossibly, but clearly not reflective of the kind of problem-solving one needs to be able to perform under do-or-die conditions -- and right now, dammit! -- in an actual, real, development job. The idea is to see how the candidate will break down the problem. Unfortunately this just isn't true. Perhaps the interviewer thinks, to to himself, that that's what it's about. But in practice, these almost always end up being pass-or-fail tests. And if you take just a bit too long, or temporarily forget whether a certain datatype is immutable or not, or even take a bit too much time explaining what you're doing rather than furiously typing or writing your knuckles off... or, horror of horrors, you give a perfectly reasonable answer, but not the one the interviewer "likes" ... Then forget it, you're screwed.