Bull. It teases out if someone happens to know the GetHash() implementation in C#. Their knowledge of .NET and C# can, in no way, be determined by one stupid question about the implementation of a specific function in C#. Evidence of that fact is in your actual response: I could now answer that question, having never used .NET or C#.

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.

I do not think we disagree.

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.

That's not the question being asked.

"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.

> It teases out if someone happens to know the GetHash() implementation in C#.

Even if that's all it teases out, that alone can make the mark between a solid programmer and someone whose "been doing .NET since it came out".

In Ruby-land, I might ask "what's the difference between extending and including a module?" If you've only ever done Rails apps, you'll never have any reason to have to figure out the difference. But the second you write anything non-trivial in Ruby itself, you'll inevitably run into it when you start refactoring and extracting. Hell, a core Ruby module (Forwardable) wants you to extend it rather than include it when you use it, the curious will want to find out why.

If I'm interviewing 10 guys for a Rails position, I'd ask all of them that question and rate more highly the guys know their basic Ruby better. Maybe none of them could answer it. Fine, no big deal. But the one's who can demonstrate immediate, real value to me. Even if all you have is a "yeah, I had to look that up a few months ago, what kind of project was that again...", is better than nothing. Hell, even a "I actually don't know that offhand, what is it?" with followup questions to my explanation, sort of curiosity will really impress me.

Yes, I know you could look it up if and when you need to. But the fact that I'm asking the question means I've used it somewhat recently, which means my new hire is going to be reading that code eventually. If you're already familiar with code that uses those sorts of patterns, I'm going to have to do a lot less explaining to you and you won't have to spend half as much time extending it.

I don't know whether GetHash() in C# is as useful a knowledge filter as extend/include in Ruby, doesn't sound like it to me, but I do think that a carefully selected question like that can separate the men from the boys, so to speak. Do you love the little details as much as I do? Then we're going to get along just fine. If you can even just, with no guilt or worry whatsoever, just state confidently that you don't know that particular detail, will say to me that your confidence lies elsewhere and prompt me to draw you out.

When I was taking screen acting classes a few years ago, something our teacher said to us stuck with me. Everything in the class is geared towards auditions, since that's pretty much all you'll be doing for at least the first few years of your career, while you're holding down a waiting gig. He said, "have fun auditioning, because it's pretty much the only time you'll get to really display your personality and skills, for a long time." Even once you start getting gigs, they won't be like the glamorous TV or movie roles, they'll be for commercials. The interview/audition is your chance to shine, milk that opportunity.

Senior programmer would know that he needs to check hashing mechanism when his custom dictionary keys were not working right.

Everything eventually boils down to the bunch of algorithms Knuth so carefully documented for us. Learning a new language is just learning the syntax and semantics for it's mapping to those algorithms.

Stop holding languages in so high regard, jeez. IT is held back by this so much it hurts. Let's just describe some sensible high-level evaluation semantics and start all compiling into that already!

Never heard of GetHash. I've got 5000+ Web pages of documentation mostly just on the .NET Framework, am betting my start up on .NET, ASP.NET, ADO.NET, and Visual Basic .NET, and have yet to encounter GetHash.

From the mnemonics of the naming, a guess is that GetHash has to do with hashing. Well, mostly I don't like hashing and prefer extendible hashing, AVL trees, red-black trees, B-trees, heaps, etc.

Typically, for a class in the .NET Framework, to use it for the first time have to find a dozen or so Web pages at MSDN and learn them: For me that means download, index, abstract, and read the pages, look at the sample code, and maybe write some minimal code to exercise the class.

Yes, being clear on call by reference versus call by value is important but also quite elementary. Basically, all aggregates are to be call by reference; simple numeric constancts are commonly call by value.

I've been writing apps in C# for about 5 years, and not once have I needed to know how GetHashCode works.

I have looked at it at some point (don't remember why, I think it had to do with an entity's identity for NHibernate) but I would fail this question even though most people I've worked with would rate me as a very effective (and efficient) programmer.

This is why I feel I would do badly in these kinds of trivia-like interviews (once since I put linux administration on my resume, I was asked how to delimit lines in bash scripting).

My dream interview, one where I'd shine, is where I'm given a problem, and I have to go through designing solutions and discussing tradeoffs. I don't mind writing code either, but I would not know the answer to this kind of very specific question, I'd just know how to solve problems.

Have you never written a class that you wanted to use as a key in a dictionary?

You need to know the contract of GetHashCode to do this properly. If you don't know the contract of GetHashCode, well, you simply don't know .NET very well. That's my professional opinion.

I don't know much C#, but can't one understand the contract without knowing the default implementation? I would agree understanding the contract is probably essential, but the implementation is not.