"I knew that I was going to be spending the next hour talking about red-black trees and low level language trivia." I know what you are talking about. Not too

"I knew that I was going to be spending the next hour talking about red-black trees and low level language trivia." I know what you are talking about. Not too long ago, I was "that guy" - the guy whose heart sank at such interviews and couldn't get what the focus on "trivia" was all about. I know how to write software dammit why ask me all these stupid questions about the fine detail of Red Black Tree implementations and language edge cases? "There has been a point in my life where I knew the implementation details for various sorting algorithms and exotic data structures. That was called 'college'. More than a decade into my career, I simply don't remember most of it. " I had to learn CS from scratch (because I quit working on enterprise sw after 10 years and started working on projects where such knowledge was important), without a formal degree, mentors, or any guidance whatsoever. So in a sense I have traversed the opposite arc from most college educated developers. I first became a "in the trenches" programmer and then get a CS and math education (entirely self taught). I was an "architect" at ThoughtWorks (At TW, "architects" code every day) ar at least they used to when I was there) , working on large enterprise systems, when I stopped doing outsourced enterprise sw and started working on Machine Learning/AI projects and found myself neck deep in hairy math with no clue what was going on. I have sat in 3 hour meetings not comprehending a single sentence because the other guys were speaking "math-y programming" and I knew only "hands on programming". It is a terrible, sinking feeling. Which is all just away of saying, there are projects on which deep algorithmic/data structure knowledge (and other hard things) is important. And if a company's success or failure in such a project depended on finding people with that knowledge they would be foolish to ask "abstract" questions at interviews. Whether this is important enough to be probed in an interview or not depends on what the company is doing. If you are building simple db backed websites you can get by with understanding lists and hashtables. If you are building databases (like rethinkdb) is, then being very thorough the nuances of RB trees, networking, OS internals etc becomes significant. I agree that the interview should test for what the skills the job would need in real life, if that is what you are saying. I was just irritated at the stereotyping of programmers with deep CS knowledge as lacking team work and being too abstract and so on. I know from personal experience how hard that stuff is. And it is orthogonal to "in the trenches " knowledge and experience. You can be very good at both.