We're stretching the analogy a bit at this point, but assuming there are much fewer race car drivers than other driving professionals (taxi drivers, etc), wouldn't the professional race car driver be equivalent to something like the top 1% of software engineers? In which case, I agree, because I'd expect a software engineer paid in the top percentile to know (at least roughly) how all their tools work. But for everyone else, you can get really far in the industry without knowing how any of that stuff works under the hood (or at least not more than you have to for the work you do).

> Try saying "that's just a tool in my toolbox, I don't care how it works" about one of those topics in an interview.

I've met plenty of engineers who couldn't tell you how any of those things work at a low level, but still manage to maintain high-paying jobs. I've also had plenty of interviews where these topics never got brought up. Maybe that says more about hiring practices than anything else, but I think you're vastly overestimating the worth of that knowledge to most companies and individuals.

>I've met plenty of engineers who couldn't tell you how any of those things work at a low level, but still manage to maintain high-paying jobs. I've also had plenty of interviews where these topics never got brought up. Maybe that says more about hiring practices than anything else, but I think you're vastly overestimating the worth of that knowledge to most companies and individuals.

The question is also simply what you pay for and what is in a job description. To simplify, you have to pay a lot less for someone treating software solutions as blackboxes with known behavior then someone who understands what is done.

You can of course ask in an job interview about everything from compiler optimization to network intrusion detection to image processing, but you better should make sure that is actually what you need.