[jussij]

> For all the arguments against the algorithmic type questions - i would add that in my ~16000 hours of professional programming, i have had to worry about O(n) to choosing Hash tables, quiet a lot of times.

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.

[fayyazkl]

I sort of agree to most. Being able to write recurrence out of master theorem is never kind of thing really needed here. Even if you know conceptually the running time of a loop (nested ones etc.) and be able to apply that practically is sufficient.

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.