The problem is the way they test for this makes no sense. At most having done DS&A will flash some lights in my mind when an n^2 or higher solution comes up, ie I will think about how to do it better. But that thinking will inevitably lead me to google for a better answer, rather than plumb my limited memory capacity for how to do it. So it's a principle that relies on the right tools to get implemented, and that's rarely what anyone asks for in the interview.
More than anything else I've ever done, coding is an exploration. And nobody seems to test for that, they seem to all test for whether you've already been down a certain cave, recently. For instance, I can write a mobile app that trades stocks on an exchange through a server. I could write both the apps and the server for you. I've literally done all the bits that you would need to do this. If you ask me some random question about Swift or C++ syntax, I will fail. Because having those in my mind's cache is not sensible. Knowing that sorting is probably already a solved problem, or knowing what the unsolved problems ahead are, those are useful.
The real thing you need to do as a programmer is to handle complexity. Not in the big-o sense, but in the sense of keeping the mess of code a sensible size, in a way that allows you to make future changes easily, and allows collaborators to contribute easily. This is both a code thing and a people thing. Yet I don't come across a lot of people asking about how this is done.