(I've known many engineers who wing things at work rather than spend the time to research a correct solution, and not just in software.)
That's not been my experience. I've seen a strong correlation.
> show their willingness to do whatever they are told
I don't think it's the same thing. I've told many of the people I've worked for that what they asked me to do was a waste of their resources. One told me "do it 'cuz I'm the boss and I say so" to which I replied "at the salary you're paying me, I feel obliged to tell you that what you're asking will never work". :-)
Nevertheless, if you know upfront that at a job interview you will be asked certain questions, and you choose to go to the job interview, it seems bizarre to not come prepared. Why bother?
Like said, might be culture or maybe I have been lucky.
In my country (I haven't lived there for a while so might've changed but I don't think so) and my company we were not so salary obsessed, so 'at the salary you pay me' is a phrase used never in our office of few 100 colleagues. If you make 5 or 9 figures a year; if the boss tells me 'do it cuz i'm the boss' I'm not doing it if it's a stupid idea and I expect that from my colleagues even if I outrank them technically.
So still thinking it's culture as well; here you cannot fire people easily; you have to make a dossier (with obvious mistakes/flaws etc) and go to a judge and then pay them a few months. So there needs to be much more of a trust relation than master/slave relation imho. Note that we only needed that twice when the employees where watching/downloading pr0n all day. One was a junior designer and the other a phone support employee for our cms.
Edit: btw, i'm not saying I like that system per-se; in some countries (like Spain) it goes too far and you won't hire people because you can't fire them, but in NL I had no actively sabotaging people (you can't fire me so I do just enough); quite the opposite, while in Spain I meet too many of them.
None of this should be construed as a master/slave relationship.
For an analogy, if I go to McDonald's I am not interested in the opinions of the cashier, I just want to pay the money and get the burger. If I'm going to an expensive restaurant, I'm interested in the opinions of the waiter about what to order - that's part of what I'm paying for.
Ahem, Walter writes programing language compilers for industrial use. I strongly suspect that algo prep will make them better at their job if he was involved in the hiring :-)
It's not like one can look some detail up when he doesn't remember the detail was even there. Good software programmer needs a large working set of such details to sensibly function in a professional setting.
For another example, nobody knows every detail in the C++ Standard. But a professional is expected to know how to look up a detail in the Standard as required. That doesn't mean he doesn't understand the language.
Maybe you never need to look anything up. But I'm not that kind of person, and don't know anyone that is.
It's not like that. I do need to check various things, and I daily run `man whatever' (I'm a sysadmin in large part). But even though I often don't remember what was the switch for e.g. `grep' or `find' or `awk', I wouldn't "bomb the question" about that. I would just substitute a sensibly sounding switch, explaining that I'm doing so (and why) and what the switch was supposed to do.
The same stands for algorithms, data structures, or program architecture (in other large part I'm a system programmer). I don't remember how AVL trees do inserts and deletes (frankly, I never learned that properly). I don't remember exactly how inserts and deletes work in B-trees. I never implemented my own hash table. But I still wouldn't "bomb the question" about any of those, because I understand how they work, and the details either can be worked out pretty quickly, or most often are not important for a particular question (unless, of course, the question was "how to insert an element into AVL tree"; then I can at least give high-level answer before calling for data structures handbook for lower-level work).
Heck, I don't even remember most of the cryptographic details. Every time I need to explain RSA or ElGamal encryption algorithms or Feistel net, I need to derive the formulas (I typically don't have any reference handy).