As a general rule, we actually have a pretty terrible success rate for people who walk in with post-grad degrees and not much other experience. The average age on our team is probably about 40, and I think about half come from CS backgrounds. I don't doubt that there are interviews out there that stray more towards demanding that somebody know exactly how to implement a quicksort, but I also think there's a tendency to classify any question that causes one problems during an interview as too computer sciency and not the part of programming that really matters. But we ask the questions we do because we think they tend to be good indicators of how well a candidate understands the ramifications of their code and can solve hard problems.
There's a lot to be said for what somebody can get out of years of experience, but given the choice between the inexperienced guy who has the capacity to solve the hard problems and the veteran of the industry that knows the tricks of the trade but will struggle on things that are involve challenging algorithms, I'd take the inexperienced guy. If you give him a couple years to gather experience, he'll be able to do everything the mediocre veteran will and more. And as long as you have some veterans on the team and decent collaboration, they can cover any gaps knowledge gaps he has in the meantime. Thus, my interview process is going to select largely for the former.
Of course that still requires me to hire or retain some veterans who can solve hard problems, but as long as you don't require them to quote from a CS textbook, they'll be able to navigate our interview process anyway. And given how hard it is to find good candidates if you're not one of the high profile tech companies, there's a decent chance you can't afford to wait to only hire candidates like that if you're looking to increase headcount.