I think interviewing at places that do interviews the right way is important. I've interviewed for senior/staff positions before when they immediately start talking about big o notation and asking me to reverse a string on a white board (seriously). Sorry but your CRUD line-of-business app with 150 total and ~10 concurrent users can use whatever algorithm the developer wants, and if anyone is reversing a string manually there is a problem. It's not even worth continuing the interview if they're asking a senior candidate junior-level questions.
Interviews for senior level positions should contain almost no technical questions at all - you can tell pretty quickly if someone knows what they're talking about by digging into their experience with earlier projects. How was a solution architected? What other ways did they consider? Why did they go the route they did? And my favorite, "think about the most complex project that you had a hand in architecting (for architects) or developing (for developers), and teach it to me." You can immediately see where they focus, what things they gloss over, and if you have time and it's an engaging conversation, changing one of the core pieces and asking how they'd change the design can be a lot of fun (for an interview, anyway).
I agree, and this is how dev interviews always were up until I'd say about 2010 or so... but if you stroll through past conversations on HN about this topic (interviewing) you will see there's very strongly two camps but a _lot_ of people who really feel that the kind of interview you are describing lets in too many false-positives and leads to deadweight people who "can't code."
I think of programming as a creative process. And like any creative process, set and setting are extremely important.
Interviews for senior level positions should contain almost no technical questions at all - you can tell pretty quickly if someone knows what they're talking about by digging into their experience with earlier projects. How was a solution architected? What other ways did they consider? Why did they go the route they did? And my favorite, "think about the most complex project that you had a hand in architecting (for architects) or developing (for developers), and teach it to me." You can immediately see where they focus, what things they gloss over, and if you have time and it's an engaging conversation, changing one of the core pieces and asking how they'd change the design can be a lot of fun (for an interview, anyway).