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

81–90 of 164 posts

Re: If Carpenters Were Hired Like Programmers

#81

Post by nawitus »

frostmatthew wrote: post #57
spiralpolitik wrote: post #27

Accurate, but missed the part where the carpenter is asked to build a cabinet by drawing it on the whiteboard.

The point of whiteboarding isn't to "build" correct/functional code - it's to get an idea of your thought process and how you go about solving a problem. It's not perfect (and there are both advantages and disadvantages to using a computer instead of a whiteboard) but when done correctly it gives a lot more useful insight than sitting there asking questions about their past the whole time.

Why is thought process relevant? Different people have different thought processes. I would estimate that recruiters would bias to hire candidates that have similar thought processes to themselves, even if that doesn't correlate well with actual work performance.

Re: If Carpenters Were Hired Like Programmers

#82

Post by ukigumo »

DanielBMarkham wrote: post #10

It's worse than that. The CHAOS study, among others, shows that 80%+ of all software projects are viewed as failures by the people who pay for them. Meanwhile you come onto boards like HN or reddit and instead of talking about how to establish and keep trust with the folks writing the checks, everybody's talking frameworks and tools. So picture a subdivision where 80% of the houses are broken down, priced too high, i…

I wrote about the different worlds of people that form the bulk of the CHAOS study and what seemingly is the crowd on HN and Reddit at https://blog.ukigumo.eu/3-types-of-company/

In short, most projects fail because many companies either don't understand IT well enough to take advantage of it or are too focused on IT to understand business.

Re: If Carpenters Were Hired Like Programmers

#83

Post by [deleted] »

jhall1468 wrote: post #60
barrkel wrote: post #54

Earlier quoted context omitted.

What's the default implementation of GetHash() in c#? I actually like this question (not that I've ever asked it before), because it teases out how well someone knows .net and C#. The specific implementation of GetHashCode isn't what's interesting. It's whether you know that .net implements reference vs value equality by default, whether you know you really do need to override GetHashCode if you override Equals, test…

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]

Re: If Carpenters Were Hired Like Programmers

#84

Post by jasonwocky »

sjclemmy wrote: post #70

As someone who occasionally has hiring responsibility I sympathise with both interviewer and interviewee. It is extremely tricky to determine if the person you have interviewed is going to fit the bill. I've hired people who I thought would be a great fit for permanent roles but turned out to be the worst kind of procrastinating, one trick ponies who caused more problems than they fixed. In a recent situation I had a…

> 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 because many companies are habitually reactive when it comes to hiring.

I don't follow a lot of sports, but I follow NFL football. Each year, the teams get to "draft" (a/k/a hire) incoming players from college. When it comes to the NFL draft, there are two prevailing philosophies: "Draft for Need" and "Draft Best Player Available". Without question, teams that stick to more of a BPA approach tend to have longer term success. Teams that draft for need sometimes get that player that helps them get over the hump and win a championship, but more often they're trading away long-term greatness for some short-term pain relief.

I think hiring for software teams (and just about anything where there is a lot of variance in depth and breadth of skill) follows the same pattern. Hiring for a specific role is an antipattern (albeit sometimes a necessary one). If you have a very specific role to fill, perhaps a freelancer or a consultant might be a better fit for easing the short-term pain. Then you let them go as soon as they're no longer needed.

Re: If Carpenters Were Hired Like Programmers

#85

Post by jethro_tell »

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 down for a job I was perfectly qualified for because I 'didn't seem eager enough.' Other notes from the interviewer said 'I'd be ready to go day one' and 'seems easy going and easy to get along with'

What the fuck is wrong with people? When did working at your shit company have to be my passion instead of my job?

Re: If Carpenters Were Hired Like Programmers

#86

Post by Retric »

jhall1468 wrote: post #60
barrkel wrote: post #54

Earlier quoted context omitted.

What's the default implementation of GetHash() in c#? I actually like this question (not that I've ever asked it before), because it teases out how well someone knows .net and C#. The specific implementation of GetHashCode isn't what's interesting. It's whether you know that .net implements reference vs value equality by default, whether you know you really do need to override GetHashCode if you override Equals, test…

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

Re: If Carpenters Were Hired Like Programmers

#87

Post by vonmoltke »

dsr_ wrote: post #72
spiralpolitik wrote: post #27

Accurate, but missed the part where the carpenter is asked to build a cabinet by drawing it on the whiteboard.

Actually, a carpenter who is asked to build a cabinet will start by asking you about what kind of cabinet you want, and a sketch on a whiteboard will work as well as anything else. Where is it going to go? How big should it be? What's the purpose? Is it going to be built-in, or standalone? What's your budget? Do you want doors, and if so do you want glass in them? Shelves? Drawers? Some combination? Are there exsting…

Two points:

First, nobody expects a cabinetmaker to draw a to-scale, installation-quality blueprint on a whiteboard like many companies expect out of whiteboard coding exercises.

Second, a cabinetmaker's portfolio will consist of multiple photographs of completed jobs. It will likely not include detailed specifications of the jobs or records indicating what specific parts of the jobs this cabinetmaker was responsible for and what other carpenters did. It certainly will not include the ability to inspect the actual work done. This industry expects candidates to have a portfolio such that this level of inspection is possible.

Re: If Carpenters Were Hired Like Programmers

#88

Post by icebraining »

belorn wrote: post #30

A clear difference between a carpenter and a programmer is the liability inherent in the work. A carpenter can't just produce a minimum viable product that just happens to break down as soon as a bird land on it, or leaks water as if it was constructed like a sieve. Hiring a carpenter is a comparable safe thing to do, as the worst thing a lawful carpenter can do is overcharge his clients/employer. A programmer on oth…

So if a salaried carpenter does a shoddy work, does the employer get reimbursed? I find that very hard to believe.

Re: If Carpenters Were Hired Like Programmers

#89

Post by frostmatthew »

perdunov wrote: post #18
alricb wrote: post #11

Are interview questions this irrelevant? Because there are relevant questions you could ask a carpenter in an interview, like if they've worked with I-joists, whether they know what a nailing schedule is, whether they're familiar with a "California corner", their health and safety knowledge, etc.

I would say that passing interviews is a separate skill, different than doing actual work. They are not completely different, of course, but different. This implies that the irrelevance is pretty high, otherwise you would not need to prepare specifically for interviews.

This is true of any job though.

Even though there is a difference between "interview coding" and "real life coding" an advantage of our profession is that we can have interviews that can give more insight into how someone will do their job than just asking them questions. Imagine hiring a manager - you can't "whiteboard" management.

Re: If Carpenters Were Hired Like Programmers

#90

Post by rapind »

thomaskcr wrote: post #50
TamDenholm wrote: post #39

Earlier quoted context omitted.

Yeah exactly, was once given pencil and paper and asked to write some code. That was early on in my career, so even though i knew it was ridiculous, i didnt have enough confidence to tell them they're being idiots. At this point in my career however, i'm far more jaded about stupid interview techniques like that and will refuse to do them unless provided with a computer.

Why wouldn't you just do it? I can understand if they're nit-picking syntax but I personally ask people to write out algorithms/code on the board all the time in interviews. I don't care about the code, I want to see them think through a problem. They can use any for syntax they want, even mix and match things like brackets and indentation or how control structures are defined (for i = 1 to 10 { .. } ), or use a func…

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 qualified to address it.

If however you're building CRUD apps in Rails or SPAs in React, you may want to take a different approach. One that prefers maturity, discipline, and self-motivation over pure intelligence or proficiency with Haskell.

This comes from personal experience hiring very smart people who lack some of these other values. It's never worked out well in the long haul.

I also think that there are a lot of really smart people who will just suck at those algo type interview questions because it can be a bit nerveracking and as you can already see from some replies to this thread, it can be taken as offensive (even if you don't think it is). Making your candidate (more) nervous and / or defensive and you're limiting your ability to find out about their other virtues.

Post reply on HN