3 ms·

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 qu

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

deleted 12y ago
[deleted]
Retric 12y ago
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'.
- DanielBMarkham 12y ago
  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.
  - eropple 12y ago
    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.
    - DanielBMarkham 12y ago
      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 :)
- barrkel 12y ago
  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.
  - Retric 12y ago
    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.
vinceguidry 12y ago
> 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.

deleted 12y ago

[deleted]

Retric 12y ago

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

DanielBMarkham 12y ago
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.
- eropple 12y ago
  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.
  - DanielBMarkham 12y ago
    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 :)
barrkel 12y ago
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.
- Retric 12y ago
  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.

vinceguidry 12y ago

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