Find intelligent people who can learn. I don't agree that knowing these details is important all the time. I do agree it is sometimes important based on environment. In yours, it sounds important. So find smart people, and train them. Good programmers should be able to learn nearly anything programming related.
If low level details are really important to your company and your existing frameworks, then you NEED somebody with that type of knowledge, or at least the ability to learn it quickly.
However, training finding somebody with that knowledge is difficult, and training somebody before they can add value is a high risk proposition.
You may want to look into refactoring out that low level code into a seperate codebase, this will allow you to hire juniors without this indepth knowledge to add value, and fewer hard core developers will be needed to maintain the low level stuff. And you will find through trial and error the junior developers who have the interest and intelect to be trained in the low level code.
Just my 2 cents.
I agree on the training. However one thing which I have to fight is the attitude that why I need to know these details. I think CompSc programs in the US are unfortunately producing application developers rather than software engineers. All Master level courses should have extensive course work in C, more implementtaion OS/Algortithms courses rather than just theoritical. Java/C# etc should not be used as teaching languages.
ad 1. If think the level of detailed knowledge required very much depends on the type of software - or rather on the type of features someone is implementing (e.g. if someone does mainly user interface programming, we will probably not need to know all low-level details of how the data he is working with is accessed, while someone building the business logic or database layer will need those). Thus, I'd only confront those programmers with the low-level issues that really need them to do good work.
ad 2.+3. We have a somewhat similar situation in our company - the database layer and some of the business logic code is very old and written in C (now it's actually C++ since we refactored all of the code, a costly but worthwile effort), while most of the add-ons (various user interfaces for different platforms) are written in C#. We also have troubles finding developers willing to code in C - it turned out that is was easier to hire older programmers (who grew up with C and still like it) than finding youngster willing to take what they personally considered a step back from e.g. C# to C.
We have a similar situation here as well. To some extent, we deal with it by segregating our code base and developers. Those developers with less-experience, knowledge, and fewer skills work on the less complicated modules. Developers with more experience, knowledge and more advanced skills work on the more complex, sensitive, and interesting modules.
To some extent, this categorization also serves as a motivator for the junior members to improve their skills as they know it will lead to more interesting assignments. Similarly, it relieves the more advanced developers from having to deal with the more mundane tasks that don't keep them interested.
I learned all the low-level stuff in school and was actually quite 'into it' for a while. It's interesting stuff. Most of my peers weren't so interested in the details. I'd say it's important for a junior developer to have some background in the areas you mention.
However, I should add that since I've been out in the 'workforce' I haven't needed any of those skills in even the vaguest sense -- probably because I got into web development.
So, part of your question asks if it's primarily necessary to know the details of compiling/linking/etc depending on the kind of development you do -- and to that I'd say: Definitely.
If your company does work in that area you obviously need developers who are familiar in the area but I wouldn't say that, if I were hiring, it would be a deal breaker for a new grad not to have serious interest/experience in assembly... it just wouldn't be relevant for a job like mine.
I'd look for a firmware programmer who wants to cross-train into the desktop environment. The firmware world needs precisely this level of familiarity with the low level nitty-gritty. It's an attractive option for them because desktop development is a lot less stressful than firmware... I can fix my bugs without requiring a multi-million dollar product recall. That's one of the reasons I crossed over to the dark side :-)
You may have to pay more and get someone older, but in the current climate folks will take job security over other motivators.
What you want to see in programmers is the ability to walk up and down the various layers of abstraction with ease. I think this quality cultivates with lots and lots of reading and doing ( in other words .. experience)
As an example of what i want to say: If a data structure is going to be stored in contiguous array, would you pad ( hint : virtual memory )
Or
for(int i = 0 ; i < COL ; i ++) for(int j = 0 ; j < ROW ; j ++) arr[i][j] = 0
vs
for(int j = 0 ; j < ROW ; j ++) for(int i = 0 ; i < COL ; i ++) arr[i][j] = 0
No, low level details don't matter. Many of us have programmed perfectly well in C and assembler on kernel projects without knowing the details of how microchips actually work. Knowing about hardware device interfaces is important (IRQs, ports, registers etc.) but knowing the implementation details is rarely useful.
Following that analogy, it's not important for new generation .net developers to understand assembly language, kernel implementation or physical -> logical address mapping. On rare occasions these things pop up and you have to deal with them but for 95% of business development they are merely academic exploration.
To drive my point home:
Excel users don't need to know how Excel works under the covers (but they do need to know the menus and the rest of its interface)
The creators of Excel don't need to know assembler (but they do need to know the .net API)
The .net team need to know C and assembler but probably not much about device drivers.
Driver writers need to know about the kernel API and hardware interfaces but not about microchip internals.
Microchip makers need to know about circuits, electricity and sometimes atomic structure, but not about string theory.
Interestingly it goes the other way too. Microchip manufacturers should know about driver writing yet they don't need to know about .net implementation or higher levels of abstraction. They really only need to know about the abstraction layers that are immediately above and below them (within reason).
Until low level programming is seem to pay a lot better than Java/C# and there are lots of entry level jobs in low level programming, I don’t see a reason why someone that is just leaving university would consider low level programming as a good option.