Look.
After a certain point, software engineering becomes less about handling raw data structures, or coming up with some whizbang new algo and devolves to a matter of A)plumbing and B)bridging the gap between what everyone thinks the machine is doing vs. what it really is.
I keep around my old CS textbooks. Why? Because I know they have valuable details on algorithms and such in them. Those have been sorted out, are good things to refresh every now and again, and are important in terms of knowing in which circumstances they should be applied; but don't ask someone to play the part of a compiler. Also, all that pales in comparison to the importance of actually being able to cobble together, understand, and reason through systems, and to explain the "why"s of different implementations.
I also don't believe anyone should come out of an interview empty handed, which happens more often than not with places that fall back on "lets see how they do on brain teasers!" I do my best to shift interviewers towards actually talking problems they're having or things they think they'll have problems with to get a feel for whether I might be able to immediately help them or not.
I don't find that the traditional whiteboarding exercise is helpful, especially when I tend not to do my best work until I have time to reflect on a problem without it being the spotlight of a social interaction.
All that being said, I'm not sure there is much that will change about it in the long run. So, I just try to get practice when I can.