If Carpenters Were Hired Like Programmers

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

> Regarding your first point it's extremely rare in my experience to have an interviewer expect perfect/compiable code when whiteboarding (nearly every whiteboarding exercise I've ever done has been prefaced with the interviewer explicitly stating this). They're looking for how you go about solving a problem, they don't care about missing semicolons.

The interview instructions Amazon gave me prior to my in-person interviews specifically said my whiteboard code would be judged on syntax and that I was expected to produce working code, not pseudocode. They are not the only company that has said this to me, so I do not think it is "extremely rare".

> As for your second point, just because the ability to easily "inspect the actual work done" is not practical in one profession doesn't mean it shouldn't be considered in a completely different profession where it is practical.

For a large portion of programmers, it is impractical. The only way most programmers have representative examples they can show that level of detail in is to do professional-quality work outside of their day job. Expecting them to do so is unreasonable.