I would go so far as to say someone with that kind of encyclopedic understanding of a language is a negative indicator. People with an 'deep' understanding of a language like to use said knowledge to create 'Clever' code. 'Clever' code is generally more buggy, harder to maintain, and basically never needed.
PS: And yes, I have been burned by this in the past often enough so I will now pass on a few marginal people that happen to know a language 'deeply'.
Here's my exact train of thought while reading that:
GetHash? What the frack? Isn't that on object somewhere? Right, object handles all the common copy semantics and so forth. Use the hash to check for equality; things on the stack instead of the heap, yadda yadda..
Dang, here the guy is going into detail why this is so important. Ah yes, value versus reference semantics. Boxing and so forth. Tiny trivia around how the CLR works. I remember those days well. Would make for a great Nerd Jeopardy question.
But who cares about all of that? I'll look it up if I need it. As far as memory usage, I worry about that by using pure FP and being careful what kinds of data structures I use. Problem solved.
Encyclopedic knowledge is great, but the real trick is dumping everything possible offline and then knowing how and when you should get back to looking at it.
While in the general case I would agree with you and I try very hard to dump as much stuff offline as possible, I would argue that this is one of those things you cannot look up "if you need it", similar to the difference between 'class' and 'struct' in C# or the difference between 'class' and 'case class' in Scala (the C# one being a runtime implementation difference, the latter being a fairly large OO design difference). It's something you need to internalize to do well in the language and the environment.
C# (and similarly Java) are so tightly coupled to their runtime languages that, personally, I do feel like I need to understand stuff like this at an intuitive, not-even-thinking-about-it level to be able to write good, fast, clean code.
My point was understanding the stack and heap, boxing and unboxing, were great to know general purpose knowledge about how type systems are created and used in modern languages, whether Java or .NET
If you know what it is, and you know why it is important and when it is used, then any detail you might miss or mangle really isn't that important.
In a similar fashion, I can describe in general terms how a virtual lookup table is fashioned, and how method signatures work in OO linkers. I'd probably miss 90% of the details, but I retain enough of an overview to correct myself when required. I can know something in general terms well enough to know where to go when I dive deep. That's the goal.
You have to internalize struct and class. Not so much on the relationship between the built-in hash function and the rest of it. You start using structs and classes, you start extending the type system, badda boom, badda bing -- you end up in the same place. No need to be able to give a lecture on it. Just be able to do the work :)
You need to know the contract of GetHashCode to use a custom type as a key in a dictionary. It's as simple as that. This isn't encyclopedic understanding; it's one level above novice.
"What's the default implementation of GetHash() in c#?"
As in if you call get hash code on a custom class name {public sting first ="A", public string last = "B"}; what happens and or what's it going to return.
PS: And yes, I have been burned by this in the past often enough so I will now pass on a few marginal people that happen to know a language 'deeply'.