I've got ~36000 hours of professional programming behind me and like you, there have been many a time where initial testing has highlighted a performance issues.
So out comes the hash table, the binary search, the double checking of the memory allocations or the some new index on the SQL table.
Now I know Big O tries to formalise these sort of things (or at least I hope that is the case), but is knowing the answers to these Big O questions that important?
Since I have Engineering degree I certainly can’t give a credible answer to a Big O question, but I have absolutely no trouble fixing sluggish code.
> But you should be able to recognize that a design
Unfortunately, at a lot of the places I've worked, not much time is ever allocated to design :(
Managers seem to want easy to read, high level, non technical design documents to take to their managers meetings and once those are approved they then want something coded ready for QA.
Ah... yeah for the design statement :) i can't say much beyond that for most of the companies with established practices - you have to write a design document, often down to the level of writing data structures and function names - run through debates with others to justify your choices BEFORE you can even start to write first line of code.
I understand this partially because of being in Embedded, C/C+ domain where you can literally shoot yourself in the foot due to wrong choices and often product models are different.
E.g. at one place that i worked, code reviews and conventions were very rigid, some what more than say Linux kernel, because the product was an RTOS and associated stacks, which were sold to companies WITH SOURCE since the customers were actually developers developing end applications using our APIs. So even one comment not written according to company's coding convention often won't pass a peer code review - but i believe this is a pure exception rather than the norm.
I know, I am constantly concerned about sorting that list of 100 items!
How about a gateway device receiving some minor 3-4 millions subscribers traffic and processing like 40-50Gigs per second. I suppose worrying about hashing those ips to access individual records is a waste of time, and a simple list should work? right?
The scenario is not as common as may be building a website. But it a whole industry and a whole bread of programmers exist who do this all day. You should go out more :)
Although not too often (compared to factors mentioned already), but it depends upon the domain too. I worked in embedded for the most part where the liberty of using frameworks, libraries - is far scarce, so it matters which area / programming environment are we talking about in general.
Also, i am yet to run into a good interviewer + programmer (whether more experienced or junior) who doesn't value these things as a good predictor of some one's coding ability.
And we are not talking about only scale of companies like Google or Facebook and in my humble opinion, those might get a bit tooo algorithmic as well.
But you should be able to recognize that a design you did won't scale when you have say 100k or more packets (instances) of inputs thrown at it. It won't be a problem ONLY UNTIL your list of traversal, get big enough, and frankly any software worth being discussed - gets big enough at some point.
Or that your linear traversal should dramatically improve if you could code and use a hash table instead.
Ah - and yes, loved the idea of 'can do serious work for at t least four hours a day', but wonder if there is a way to determine that.