| From what you asked, I can deduce you work in an environment where performance is important. 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. |
Sooner or later, though, that approach will come back to bite you. Milliseconds matter to the user because the longer they wait for an action to complete, the more likely they are to stop caring. They matter in settings where you're performing multiple RPCs because a millisecond of delay here and there adds up over multiple calls. Not to mention the fact that memory, CPU, and disk all cost money. And when those factors come up, you'll suddenly find yourself surrounded by people who are (at worst) incapable of addressing the situation or (at best) will need to be ramped up on the issue.
And that's just constant factor improvements. Can you imagine choosing an O(NlogN) solution over an O(N) one? Everyone thinks that's trivial, but in real terms it means a 10x speedup per thousand inputs and 20x per million inputs. That's huge.
More importantly: in interviews, a lack of care for performance suggest to me that a candidate is willing to cut corners. Once they have any old solution they pat themselves on the back and move on. We're a very self-driven organization, and in my experience if a new hire is struggling to meet expectations 6-12 months after joining, it's usually because they don't constantly ask themselves how they can improve their work and our codebase and instead expect to be told what to do.
Minor pet peeve: parallel processing is not premature optimization! If you think it is then I suggest you exercise it more. It's not as hard as people make it out to be, and at a certain point it becomes second nature. Then all of a sudden terabyte datasets start looking trivial...