After nearly 50 years I can still recite my interview (both sides of the conversation) pretty much verbatim from memory — it was, let's just say, unfriendly (but he let me into the program, much to my surprise).
Rickover believed in that AND demanded technical excellence from all of the operators. Nowadays, it seems like we automate things so that we don’t have to train technical excellence.
Rickover believed that automated systems will fail in unpredictable ways, leaving the human operators as the last line of defense. The people in the organization need to understand how -everything- works so that they can respond to these failures.
But modern orgs want to automate the things so that they can cut costs. Not Rickoverian.
Nukes are expected to understand their systems (and everything that interacts with them) at a granular level. A common final board certification question is, "How does a neutron turn my rack light on?" Depending on your rate (i.e. your specific job - reactor, electrical, mechanical, chemical), you may be expected to do a deeper dive into a specific area, but everyone will be required to trace the path from fission --> heat --> heat exchange --> steam generation --> turbine --> power buses --> light. By trace the path, I mean literally sketch the systems including pumps, valves, circuit breakers, etc.
An analogous question for tech is "What happens when you type foobar.com into your browser?" This question has enormous breadth and depth: keyboard debounce circuits, CPU interrupts, TCP congestion control algorithms, DNS, LCDs, and a thousand other things I didn't discuss. You can argue that this is all trivia for most SWEs, but I counter that if you have at least a passing familiarity with the actual full stack, you're in a much better position to understand how your day-to-day work affects and can be affected by the rest of it.
For example, IOPS seem to be a mystery to a lot of devs. I'll grant you that EBS (and presumably other cloud offerings as well) makes it a fun adventure between provisioned, burstable, implicit striping, max performance/24 hours limits, et al., but the root concept remains the same - you can perform N actions/sec of block size M. Don't forget to take fsync() calls into account, as well as blocksize mis-matches.
This stuff is so abstracted away that most people never have to see it or think about it, until they do. The magic that's occurring when you add a Persistent Volume to a Pod is incredible. There's the cloud provider abstracting away the disk, controller, redundancy, failover, etc. The CSI driver abstracting away filesystem creation, expansion, etc. Kubernetes abstracting away mount points, access controls, read/write, etc. The amount of things in the path between your app issuing a write and it landing on persistent storage is breathtaking.
> if you have at least a passing familiarity with the actual full stack, you're in a much better position to understand how your day-to-day work affects and can be affected by the rest of it.