For my startup (and I'd say at least a non-negligible number of companies), half of what you ask is just not important.
Background to read what follows: small 5-year old startup with 2 developers, which don't do anything "complicated" like ML, computation or things like (mostly apps, with a CRUD back-end).
I'll try to rephrase as what I'd expect instead:
* Big-O is not important there. What you need to know is to have some knowledge to how to leverage your DB to do things instead of looping yourself over data just queried from your DB. And that's not number one.
* Edge cases is actually a valid concern for every programmer, no matter the field
* it might be useful to have a rough idea of what you expect to offer a proper solution, but it's generally pretty obvious
* justifying a solution is also a valid concern for every programmer, no matter the field
* manually doing operations already handled by your framework/library is a red herring, barring very specific situations that require an explanation. Be it sorting, filtering or whatever.
Bonus point
* bringing manual parallel processing reeks of premature optimization (as an environment where performance isn't generally a problem, remember). It has to have a real explanation, and other obvious optimizations have to be done already. So far, I've never reached that point in my professional career (but tools I use DO use parallel processing, I just don't roll it out myself, that would be NIH syndrome)
* don't forget caching! If the cache performs badly, it's time to start investigating why, but you don't need to worry about cache performance if you don't do crazy things, for the most part.
* Testing is also important wherever you go, but I also let this one slide because entry-level candidate aren't teached that in school, unfortunately.