> I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person.

I say this after having done an M.Sc. in Distributed Systems focused on performance analysis. In a lot of cases that I've encountered, mastery of data structures and choosing languages and runtimes appropriately can completely eliminate the need for a distributed system, or significantly reduce the complexity (an efficient 3-node system is much less complex to manage than a 100-node inefficient system).

A recent example that comes to mind is a pair of similar systems, one written in Java and one written in Go. There was an approximately 80x larger memory footprint for the Java system while having similar functionality. Plus the Java system took about 2 minutes to start up (yay Spring), vs. sub-second startup for the Go binary.

I fully appreciate the high level design of systems, and these days that's what I spend a lot of my time doing, but when shit hits the fan and the implementation of the system doesn't perform the way I'd expect it to, it's time to roll up my sleeves and get down in the weeds to help solve whatever is keeping the system from reaching its full potential. Maybe that means there was a flaw in the design, but often it's just a shoddy implementation (with Pareto 80/20 fixes to make it better)

Absolutely! But you if you're interviewing, and you haven't been in the weeds lately, I think it's unreasonable to get passed up for a job because you don't know the nuances of some language specific feature.