Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If Carpenters Were Hired Like Programmers

dawood.in

Post reply on HN
Print view View original

151–160 of 164 posts

Re: If Carpenters Were Hired Like Programmers

#151

Post by barrkel »

Retric wrote: post #86
jhall1468 wrote: post #60

Earlier quoted context omitted.

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 th…

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.

Re: If Carpenters Were Hired Like Programmers

#152

Post by tankenmate »

hibikir wrote: post #124
jethro_tell wrote: post #111

Earlier quoted context omitted.

No. These are companies that I worked for for years at a time. That is not a correct analogy. I have been hired, and worked for 4 years based on a 10 minute conversation.

Imagine that instead of your competent self, you were an incompetent carpenter. How long would it have taken, on the job, for your boss to figure out you were incompetent? How hard would it have been to fire you? Because that's the big issue with programming jobs: Many places hate firing, and it sure takes a while before we separate whether someone doesn't understand the tools that are currently being used, and will…

So in fact then fear has become the biggest motivator for both hiring and firing... no wonder the industry is in a mess.

Also in the building industry, the foreman may not be a carpenter by trade but at least he has some carpentry experience; in my time in the trenches too many project managers / bosses don't even have sysadmin experience let alone programming experience. Buzz word bingo, vague hunches, me too'ism, and voodoo psychology are used as yard sticks in the hiring process instead.

Re: If Carpenters Were Hired Like Programmers

#153

Post by jethro_tell »

graycat wrote: post #148
jethro_tell wrote: post #85

Man this is the strangest thing to me. I used to be a carpenter. I would show up at your job site with my tools, you might ask me a couple questions, I've had guys ask me to lay out a wall or two off the prints. Call a reference to see if I show up to work. Then I get the job. Usually, doing something myself or my boss never had done before, and we would figure it out off the prints, and build it. I just go turned do…

My explanation: The people making the hiring decisions have two problems: (1) Ignorance about software, programming, and the associated technology and (2) resentment for the compensation level of good software developers. So, who are these hiring people? People from CEO to HR to middle managers who know less about the work than the candidate employees do. This fact is like a chicken bone stuck in their throat because…

>the hiring people, lacking any better criteria for not making a hiring mistake, basically want the candidate to grab their ankles and swear everlasting, life long fealty and commitment to their six month project.

That right there should be a sign that the candidate is getting a really good deal out of this offer, which means it's out of his/her league or you're paying way too much.

Re: If Carpenters Were Hired Like Programmers

#154

Post by derekp7 »

V-2 wrote: post #113

This answer on Programmers Stack Exchange sums the problem up very nicely: http://programmers.stackexchange.com/a/1847 > A common HR thing that drives me nuts when I'm job hunting: the implicit assumption that all coding skills are language-specific, that there is no software engineering expertise that transcends command sets. That ten years experience in Java and another five in Perl mean you'd be completely useless…

I think that's why a lot of companies are now doing contract-to-hire. First they let the contracting agency do the pre-screening, and if the employee doesn't work out the contract just doesn't get renewed.

Only problem is for the employee -- it is difficult during the contract phase, if they don't get any feedback if they will be converted to an FTE, and the lack of benefits. So for the hiring company, they will no be able to steal away any good developers who are currently fully employed.

Re: If Carpenters Were Hired Like Programmers

#155

Post by mtviewdave »

frostmatthew wrote: post #120
spiralpolitik wrote: post #79

Earlier quoted context omitted.

Which would be perfectly valid if software developers spent their entire day solving problems on the whiteboard. But we don't.

Imagine you were in charge of casting for your community theater's production of Hamlet . How would you decide who to cast? I'm guessing you would find it sensible to hold auditions. Does an audition perfectly mimic what they would actually spend their time doing come showtime? No. There isn't an audience, the lighting and acoustics are different, nobody is wearing costumes, everyone is standing in the same place ins…

>As I said above, it's not perfect, but it's far more useful than hiring someone without any coding exercises

Whiteboarding vs no coding exercises is a false dichotomy. There are ways to test coding in a 45 minute interview that don't involve standing in front of a whiteboard, writing with a marker.

Re: If Carpenters Were Hired Like Programmers

#156

Post by jasonwocky »

andkon wrote: post #103
jasonwocky wrote: post #84

Earlier quoted context omitted.

> When interviewing for a specific role, you have to think very hard about what it is you are trying to do - and don't just fall back on generic cut and paste questions. I think this is true, but it raises a question about "hiring for a specific role." I find that when companies do this, they're in a reactive mode. Which of course is going to happen from time to time, but the reason memes like the OP get born is beca…

This is a really, really cool idea. I think the danger with BPA is that if you're hiring them way too early (like... a year before they'd be firing on all cylinders), then you risk them disengaging and churning out. NFL teams have a constant amount and kind of work that's predictable every season that prevents them from misallocating investments like this - and prevents players from misallocating their labour. Softwa…

This sounds reasonable, though if you hire the Best-Programmer-Available regardless of the presence of a specific technical skill, I'd be surprised if they really take a year to get firing on all cylinders. Maybe a month or two at most would be what I would expect in the sorts of places I've worked.

Sure, some places (especially in startup land) can't even afford to wait even a month, but that doesn't make the dynamic any less of an antipattern. Instead it's just one of the painful tradeoffs people make while they need to manage their runway extra closely.

Re: If Carpenters Were Hired Like Programmers

#157

Post by frostmatthew »

mtviewdave wrote: post #155
frostmatthew wrote: post #120

Earlier quoted context omitted.

Imagine you were in charge of casting for your community theater's production of Hamlet . How would you decide who to cast? I'm guessing you would find it sensible to hold auditions. Does an audition perfectly mimic what they would actually spend their time doing come showtime? No. There isn't an audience, the lighting and acoustics are different, nobody is wearing costumes, everyone is standing in the same place ins…

>As I said above, it's not perfect, but it's far more useful than hiring someone without any coding exercises Whiteboarding vs no coding exercises is a false dichotomy. There are ways to test coding in a 45 minute interview that don't involve standing in front of a whiteboard, writing with a marker.

> Whiteboarding vs no coding exercises is a false dichotomy.

Sorry, it wasn't my intention to suggest those were the only two options (I was attempting to comment on the benefits of coding exercises, regardless of method).

Using a computer is certainly as good or better than a whiteboard. Though one of the bigger downsides to using a computer is there's generally this expectation you need to write "real" code that actually compiles and runs and so the focus becomes as much on writing syntactically correct code as about how you solve the problem (when only the latter has value).

Re: If Carpenters Were Hired Like Programmers

#158

Post by Retric »

barrkel wrote: post #151
Retric wrote: post #86

Earlier quoted context omitted.

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 th…

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.

Re: If Carpenters Were Hired Like Programmers

#159

Post by rapind »

thomaskcr wrote: post #106
rapind wrote: post #90

Earlier quoted context omitted.

I'm not a pro at hiring, but I have a very different approach based on what ultimately ends up being useful in an employee over the longer term for us. If you're building a garbage collector, or a high performance graph database, then by all means, ask your candidates to whiteboard algorithms for you. Fizz buzz the crap out of them. In fact hiring for that type of position must be ridiculously hard and I'm not qualif…

I agree but usually the type of questions I asked are geared towards what I'm interviewing for. Whiteboard problems are just jumping off points, from there the problem can go so many directions based off of that person, their experience, what's important to them, etc. For a CRUD full stack app, you're right I really don't care about your ability to write a search function since SQL will do that for you just fine - in…

This is sensible. I tend to do a similar approach based on going over some code they have written and their decisions with them.

Re: If Carpenters Were Hired Like Programmers

#160

Post by scintill76 »

barrkel wrote: post #150
atonse wrote: post #135

Earlier quoted context omitted.

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-l…

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.
Post reply on HN