Working at bigcorp for 14 years so far and I struggle to think of a single day where I didn't need to consider algorithmic complexity or efficiency. Do you not write code that fetches things from a database? Do you not need to make tradeoffs between how much data you fetch at once, which fields you load, which things you cache, whether your query joins on the db or materializes things separately, whether you lazy or eager load, whether you are doing a O(1) or O(n^2) lookup and the tradeoffs, whether you can use a db index or not, memory/latency/compute/storage tradeoffs, etc? I feel like in even a simple bigcorp SAAS you need to consider this stuff daily.
Unless you are dealing with data at true scale, and not many people are, often the imperfections are hidden because they run fast, even if they are quadratic. I'm more referring to being actually forced to sit down and write out your own algorithm in a novel way.
Yes, during my BigCorp tenure I had to think about complexity all the time, but 99 times out of 100 there was an off the shelf tool available for my specific data structure and I didn't have to think about the algorithm at all beyond "oh there's a library that solves this for my specific data structure, and it's O(N)log n that will be fast enough". Whereas so much attention in interviewing traditionally was based on these "write a bubble sort algorithm from scratch" type questions which your average engineer basically never has to do on the job unless they are operating in a very high performance/scaling type of role.