While I might generally agree that the interview process is asinine and a rat race, I actually use some of those formal methods and algorithms in my day-to-day

While I might generally agree that the interview process is asinine and a rat race, I actually use some of those formal methods and algorithms in my day-to-day work--and I'm not even a computer scientist, nor do I have a CS degree. I'll bet things are different in the startup world, but I've encountered several instances where having a very crude understanding of time complexity served me well. Hashing has been an especially powerful tool in my work, where the size of the data I work with really highlights the difference between an O(n) operation and an O(1) operation. I would consider the interviewer asking questions about algorithms to be a sort of Fizz Buzz for the more technical positions. Perhaps it is misapplied to be asking technicalities of algorithm questions to people that will be doing more design-oriented work, just as it may be inappropriate to ask your sales force applicants to write programs during their interviews. That said, most of the interviews I've conducted would not have been able to discriminate well the qualities that I believe make a great programmer. A focus on code longevity, discipline in conducting code review, dedication in writing unit tests, and how they search for information they don't know the answer to are important qualities that a technical interview will largely be unable to see.