I'm not saying you're wrong, but I feel like there's a piece there that's missing.
I'm not saying you're wrong, but I feel like there's a piece there that's missing.
The mechanics of the language will be a very minor speed hump compared to changing problem domains. You can signal for that with specific programming languages, but realistically a hiring manager should be most interested in finding someone who understands the core concepts of the problems at hand rather than any specific language.
If solving a problem implies directly accessing a CPU register then realistically that part of the problem is going to get solved using Assembly. If twiddling bits on the CPU isn't needed then other languages will just be faster to move from nothing -> problem solved -> solution in maintenance mode so Assembly should be avoided. This decision doesn't really hinge on the programmers preferences.
I'd also presume that more companies would ask them to do so than those who have legitimate business reasons to write something in assembly. We are long past the age of resource-constrained architecture hacks. The closest most people should be getting to metal is ANSI/ISO C, and the others are all writing compilers or doing extreme optimization stunts.
Can I write in assembly? Yes. Should I write in assembly? Hell no.
Those companies that still require COBOL/mainframe programmers have had literally decades to watch the center of mass of the software industry move away from that, and then still make a conscious decision to pursue a dead-end path to obsolescence.
Assembly isn't Linear A.
COBOL? :)