Fair point. But is it not much more common to encounter a programer who cannot break a complex system into loosely coupled components? Or who does not use consistent naming conventions? Or who is smart but lazy? I'd rate all of these as equally important things to try to evaluate in an interview.
I am a strong believer in looking for strength in an interview. Someone really rocking complexity analysis is a strong positive (shows that they are smart and pedantic in a good way). But so does clean, smart code and great loose coupling.
Oh, I'd never disqualify an interviewee purely for not knowing this stuff, but it is useful to know.
[edit]
Also, I care far less about whether they can solve some problem on paper about asymptotic complexity than if they have some sense of what it means. Someone with little formal training who discovered the classic python "Add to the end of string" algorithm is N^2 and figured out a working knowledge of N^2 vs. N is better than someone who memorized a bunch of math but can't apply it because it went in the "math box"[1]
I am a strong believer in looking for strength in an interview. Someone really rocking complexity analysis is a strong positive (shows that they are smart and pedantic in a good way). But so does clean, smart code and great loose coupling.