I'd wager that in 90+% of the programming jobs out there you have literally zero need for information on how string literals in C work, or what structure alignment and padding are. Unless you work with C, or do some extremely performance sensitive low level work it really doesn't matter.

What matters in most jobs is getting stuff done, and that can be done by focusing on the actually important bits. Most of the software architecture today can solve the performance, availability and scalability issues etc. on a much higher level so that they don't have to care about the C-level details.

One sign of a senior engineer is knowing when to ignore the low level details and micro-optimizations and focus on the higher level architecture.

This forum seems to be quite annoying, people coming up with their hypothetical flaws in other people's arguments and glaring generalizations. You seem to be hinting that "if you don't know how string literals work in C your app is going to be bloated and have poor performance". That's simply garbage.

I quite specifically said you should focus on the important bits, and performance, scalability, good code quality and such are much more important than the low level internals of a programming language. These problems are generally solved at a MUCH higher level on the architectural design, except in a very few special cases.

In case of apps proper use of concurrency models and such is much more likely to affect your performance, than finding the most optimal way to handle strings. Similarly in the web it doesn't matter if your request takes a few more CPU cycles to complete if the architecture is solid and the system scales well to incoming traffic.

No, I literally never have to know the low level details of how strings are implemented in language X to know that it is more than likely unrelated to any performance issues I might be facing.

For example you don't have to know the low level details of how strings are implemented to know that loading a 2GB text file directly in RAM and trying to process it is not quite as efficient than processing it in small chunks.

You definitely do not need to know the low level details of C strings to know which bits are the important bits for you to focus on, unless you're working on some very low level implementations using C strings, and most people aren't.

That was merely one example. There are plenty of others. One is some developer was putting expensive function calls as arguments to a debug print function, so even when the debug printing was disabled, the function arguments were still being called (and their results discarded). In this case, he obviously didn't know that function arguments are always evaluated. That's a fairly low-level thing, but it can kill your performance.