If I was an interviewer, I would want any programmer to know these things. If you don't, then likely you know programming by pattern matching, rather knowing the spec. Leaning by pattern matching is a fine way to start, but a professional programmer, you need to understand the language. These details are a proxy for knowing the language fully. Believe it or not, knowing these things without looking them up, while not useful on your own, if you don't know these things, you don't know the language to the level at which I need you to know it. Full stop.
I've been in tech for almost 20 years now. I've worked in all sorts of industries, small companies, start-ups, big companies, you name it and I've been there. I'm currently in FAANG. I've been tech lead, in management, and even offered c-level positions in the past. There has not been a single time in my entire career where such a thing was even remotely true. Having been the interviewer before on many occasions, if I heard a candidate speak this way, I would absolutely not hire them regardless of how well they performed otherwise. This reeks of "I can't work well with others, so it's my way or the highway". It's very toxic and I question if you're trolling at this point.
I'd rather the candidate shows an acquaintance with profiling and debugging tooling. If they're good with those they'll figure out which data structures aren't a good fit once it starts to matter.
Learning some numbers and names by rote doesn't mean you actually understand the trade-offs they imply.
Don't they also dependon the architecture you are programming? 8-16-32-64 bit computers? Or did they standardise the names since I learned C (and never used it) 30-40 years ago?
This was about C#, not C or C++. So it's a little more involved. The CLR, which C# targets, has explicitly sized types. There is no "int", there's only "Int32", which is a signed 32-bit integer.
C# maps keywords to certain CLR types. "int" always maps to Int32. It's a guarantee in C# and I think a requirement of all languages targeting the CLR.
I could imagine a team that needed it, but most professional programming work does not require this level of memorization, I'd have to see the job description to know which side to take in this argument.
This isn't about knowledge.
If you can't compute that a 32-bit integer is 4 bytes, or have the knowledge that an int in c# is 32 bits and a long is 64-bits, then no, you don't actually know enough to be on a team. And yes, it does come up and yes, it does matter.
