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.

How often you have to take algorithmic complexity into account depends on what level of the stack you're at, but even at the application level, I think understanding algorithmic complexity is still important.

I was working at Company X around 2013, and we had a Rails ecommerce site. Trivial in the algorithmic sense. Had a contractor that pushed a change that somehow made everything crawl. When we did profiling together, it turned out he had written an O(n^2) algorithm when looking up country codes or something. Sometimes, there's no off-the-shelf library, and it's the minimum a dev should know not to do.

I'm not saying it should be a maniacal focus, but it should be taken into account. Of course, it's with judgement. We get shittier and shittier software if it's not taken into account at all.

>I worked at bigcorp for half a decade before all of the LLM stuff and there was exactly one time I really had to give a shit about algorithmic complexity in that entire tenure.

Conversely, I've got a PhD in math, and all my tenure (whether it was bigcorp - Google, etc - or smallcorp) was about algorithms and performance where off-the-shelf library does not exist, and you can't throw compute at the problem to do it the dumb way.

To each their own.