That is what gets me about these interview questions. I know a lot of very clever people. I am carefully differentiating 'clever' from 'smart', by the way. So many that are superficially fast and smart about solving whiteboard problems are terrible at all the things that actually seem to matter when it comes to creating value:
* Keeping a project on budget and schedule
* being able to create a budget
* managing people and resources
* Grinding out boring, but bug free code
* Writing clean code
* Being able to refactor
* Design software that is maintainable
* not tick off the people around you
SW engineering is a big, fuzzy, ill-defined optimization task in n-dimensional space. There are plenty of clever people that aren't very good at that sort of real-world iterative process. Sure, it is great to have a few people that can quote Knuth (if you don't know what algorithms are available, you'll often choose a substandard one), but by and large I want an engineer, not a scientist. A good one can learn red-black trees, or whatever, when it becomes necessary. The converse (a CS-y type person becoming productive in an engineering environment) seems less likely to occur, in my experience.
Yes... I ran a small group where we all got too inward focused being clever in our code and optimizations, all the while ignoring (for various reasons) that we had less income each month, and eventually folded.
I've since seen this firsthand at a couple other companies, on the inside and outside, where engineering types get way too focused on trying to hyperoptimize for a theoretically possible scenario X, while ignoring real world tickets that are costing them customers daily. They don't seem to realize that... when enough days pass, and enough customers leave, there is no more money to pay them.
Having lived through a couple failures (personal and professional), it's probably easier for me to spot these behaviors (again, because I used to do it myself). In my case, I wish I'd had someone early on beat that out of me - I simply wasn't aware of what was going on. As much as you can say "people have to learn for themselves", I don't believe that's the right attitude to take when the fate of a dept or company rides on what you're doing - too many other lives are involved.
This is in reaction to your 'budget' stuff above - I don't expect people to be Excel/Quickbooks/Peachtree gurus nor CPAs, but understand that you have to get stuff out, on time, and sometimes have to choose your battles and put out less than optimal code, then have a plan to address the known shortcomings.
I agree too on the CS adapting to engineering being more rare than engineering adapting to CS.
+1