If carpenters were hired like programmers (2004) | Hacker News Reader

If carpenters were hired like programmers (2004)

dawood.in

66 pointsrmason48 comments

I hate to be so negative, but... ugh... This reads like a rant written by someone with very little professional technical experience, and it's just such a poor analogy.

Yes, there are a few tools that are as interchangeable as various types of wood, and there are some weird dogmas out there analogous to using rocks as hammers. But these are exceptions, not the rule.

Languages aren't interchangeable. Sure, any half decent programmer can pick up any sane language and be hacking something together in a day or two. However, most languages have idioms and subtle usage patterns that take far more time to learn than you'd estimate. You've mastered first principles? Awesome. Ever heard of an "unknown unknown?" This kind of thinking will have you tripping over them constantly. The best part is it will always look like you're tripping over your own shadow.

And guess what? Tools do have meaningful impact on the way you perform your work, and even how you think about problems. Sometimes these tools are old and at first they look a bit like swinging a rock, but the people around you with more experience are probably using them for a reason. Go find out what it is.

Actually, that brings about a larger point. If you find yourself agreeing strongly with the OP, maybe you need to force yourself to work through a different set of languages/frameworks/platforms/tools/philosophies for a month or so and test the idea that it's "toe-may-toe/toe-mah-toe."

> Languages aren't interchangeable

I disagree.

If we're talking about building websites, there's a dozen of languages that you can pick from and they are all fine for making a website of almost any complexity.

Yes, you personally will (likely) prefer one language over every other. That doesn't mean anything.

There are really really profitable websites out there written in PHP, Java, C++, Ruby, C++, C#, Pascal, Python, Go, LISP, Javascript, etc.

Maybe I should've qualified that better. Languages can be interchangeable in purpose, but not in process. By that I mean that sure, I can write a web backend in pretty much any language I choose, but the quality of that backend code and the rapidity with which I can deliver it will heavily correlate with the amount of experience I have with the language in question.

I agree, but men... a joke is a joke, and I found this one funny.

Oh, don't get me wrong... I see the element of humor, especially when you imagine that the interviewer is the worst kind of dishonest bullshit-artist-wannabe recruiter from some very nontechnical background, and the job description is for a 'top 50 company with millions of users.' It's just the line of reasoning it promotes that makes me cringe.

"I don't understand why X is different to work with than Y, but I know that X and Y can be used to accomplish the same goals so they must be interchangeable."

Now imagine that being said by someone who is somehow responsible for setting your deadlines and for whether or not you get paid. I've dealt with that too many times to find it funny anymore.

You're right. They should be discussing the brand of the hammer.

Psh, there's no need to discuss it. Anyone who's ever framed knows it's best to swing an Estwing! :-)

It can get pretty silly in any technical field:

Q: So, your resume says you've been a systems administrator for 10 years. Have you worked much with Linux?

A: Sure, almost all my experience has been with Linux.

Q: How much experience do you have with Red Hat. That is what we use here.

A: Hmmm. Red Hat. Most of the servers I've worked on are Debian based. But I worked a lot with Fedora in college.

Q: But not Red Hat?

A: Well I have some Red Hat experience. I had a temp job where I was setting up Red Hat servers back in 2008.

Q: How long was that.

A: About six months.

Q: Well, perfect! We have an internship available to someone with six months of Red Hat experience! But wait a minute... What version of Red Hat was that?

I've had this very interview, repeatedly, usually someone who doesnt know the difference between debian and a toaster oven.

In pretty much all of my interviews, there were always three phases:

1. The interviewer asks about my portfolio, previous projects etc

2. The interviewer asks obscure technical questions. I've been asked, more than once, about the structure of .NET assemblies and MSIL.

3. The interviewer asks some abstract "outside the box" question, usually involving bit twiddling (they seem to like that)

They usually like the portfolio, and I usually screw up on the technical & outside the box questions. I always feel like saying "Look, here's the work I've done, you can see its quality. This is real life work I'm showing you here, not some obscure part of some technology neither I nor you care about. Hire me on that!" I've never understood why a good portfolio isn't enough to get you hired to most places. Oh well.

This is so so true in my experience as well. I think I've got a really rich portfolio of software I've built (and shipped) yet whenever I've interviewed anywhere it is barely a talking point (even if I try to steer conversation in that direction)...instead, it all comes down to answering some esoteric technical question almost completely unrelated to the domain I'll be working in.

The way most companies hire developers today is a complete and utter fucking travesty.

Reviewing your portfolio at a level which would show prowess in technical detail requires a lot of time. Answering a few bit twiddling questions dosen't, and they're almost always required to be asked to all candidates as a matter of policy. That said, if your portfolio very very easy to browse it'll definitely score you some points. Just make sure you've got the average person from the movie Wall-e in mind when you're considering how to make it "easy to browse."

I'm responsible for a lot of technical interviews where I work. I think we've got a good process down. We have a simple "walk me through your resume" phone screen, then we send them two programming problems that take a few hours to complete, and then we bring them in for an on-site. If you pass the first phone screen and if you submit good-faith solutions to the problems, you're pretty much guaranteed an on-site.

The first of the two problems is more of an infrastructure type problem with an extensibility requirement. It involves looking for files in a directory and carrying out some simple pluggable actions on them. The second one involves writing a custom, optimized data structure. The naïve solution is very quick and easy to implement, but our performance threshold for the sample dataset requires a more advanced solution.

Almost everybody gets the infrastructure one w/o any problems. We mostly use it to look at their code style and how they'd structure an extensible program. Almost nobody submits a solution to the second problem that comes in below the maximum time specified in the performance threshold. This is okay, as the goal of the second interview is to discuss these solutions and the problem solving process that went into them in depth.

We hire a bunch of people who've gone on to perform well who didn't submit optimal solutions, and although it's rare, we've declined to hire people who did submit an optimal solution. It's the conversation we have that's important, not the code.

To be blunt, you're most likely nothing special—you're probably applying against similarly skilled candidates, so it's much more about weeding out the false positives than it is at getting any particular candidate.

Having been on both sides of the interview a number of times, I can say the primary reason I've asked the "phase three" question is more to gauge how you think and how we work together. The problem itself isn't the most important part.

This is pretty old (I think it started circulating around 2004? [4]) and was first publicly posted at jasonbock.net[1], although his site seems to be having problems so here is a cached version [2].

The intro posted there is as follows:

The following joke was posted to an internal Magenic[3] list. I don't know who actually wrote it, and I'll give credit if someone points out the creator of the joke. It perfectly illustrates what I think developers (especially consultants) have to go through all the time when they're interviewing for the next gig.

[1] http://www.jasonbock.net/jb/Default.aspx?blog=entry.7c334037...

[2] http://web.archive.org/web/20130210235908/http://www.jasonbo...

[3] http://magenic.com/

[4] From the jasonbock.net post: Posted at 10.13.2004 11:38:07 AM

So what? It's not like the internet is some hive mind where if it's existed once it's been seen by everyone. Sometimes old things are new to a lot of people.

I don't think it's wrong to repost this, I was just providing some background for people who might be interested.

When I read this post I remembered the previous one so dug it up; turns out the post references the original source, which I had missed the first time 'round.

In any case, I enjoy knowing the history of "famous" internet things, and presume to think others might too.

Fair enough, I just presumed it was a more intellectual version of the standard "OLD!" comment you see on things, which tends to annoy me.

Maybe it's just because I spend too much time lurking here, but I see a relatively large number of re-posts (or things which I have read before somewhere).

I don't usually comment on these articles, however especially when it looks like someone has lifted content I try and link back to the original (and original discussion where appropriate). In this case I was pushed to comment because I thought it was not attributed (and hence lifted) but in any case I am always concious of the type of post you outline - the 'OLD' comments.

I think a 'more intellectual' version of that comment is actually a good thing in general, mostly because it adds content rather than simply deriding, but it's always a tough question to decide if posting is the right choice or not. I'm happy enough with this post.

PLEASE STOP THE METAPHORS!!! (shouting justified by how many of these have been written)

They don't add anything to the discussion. Do you need special techniques to work with walnut? I don't know and I bet the author doesn't either.

And where do you draw the analogy? What's the programming tool that's too specialized to be worth asking about? MSVC++? C++? Manual memory management?

This article doesn't make any useful claim about what level of precision interviewers should be looking for, and certainly doesn't make any convincing argument that it is the correct level.

The carpenter made the mistake of answering the question he was asked, instead of the question the interviewer wanted the answer to.

LOTS of interviewers are going to have zero experience in the field they are hiring for. It will behoove the (carpenter|programmer|car salesman) to learn the language of the interviewer, so he or she can answer the questions the interviewer wants to ask, but doesn't have the vocabulary for.

How would you have answered differently?

I didn't find this very insightful or humorous. I guess it's trying to imply that specific prior experience is not very important which I would very much disagree with.

Actually, nobody interviews carpenters. You either:

A. Call the carpenters' union and take whoever they send over.

B. Ask some carpenters you trust if they know any decent carpenters who are looking for work, and when they show up at the job site sober with appropriate tools, you put them to work.

It's a slightly different process than programming.

Speaking as a carpenter, you're quite right!

However every so often we do have to advertise for a position, and then the process of weeding through the applications probably isn't so different from what everyone else has to do.

At this point in my career I can say that it's quite easy to spot a skilled carpenter if I spend a few hours with them. I imagine an experienced programmer could do the same. The problem is getting to that point.

> At this point in my career I can say that it's quite easy to spot a skilled carpenter if I spend a few hours with them. I imagine an experienced programmer could do the same. The problem is getting to that point.

Bingo, this whole topic in a nutshell.

Well, that why's it says "IF" they hired carpenters the way we hire programmers... The key word here is IF. It shows how nit picky one can be while choosing programmers.

Watch this HN thread devolve into a battle of contrarians, in real time!

This thread won't devolve into a battle of contrarians.

Metacontrarianism!

The irony of this comment does not escape you, I hope

This is the funniest thing I've seen on HN in a long time. So true -- a good programmer (carpenter) is a good programmer. Who cares what the latest language (wood) they've worked with?

what, really? I work either with kernel and system level code in C, or program analysis logics written in ocaml or c++. I've done that kind of programming for about ten years.

so I should seriously be able to look someone who has done web development for an equal amount of time and say "yeah, I'm a decent programmer, surely I can get to the bottom of your domain in a few months of learning as I go". really? if you had a choice between hiring someone who was an expert in a totally orthogonal domain or someone with experience in the domain you were working in, you would prioritize experience over familiarity? how is that working out for you?

The post was not really referring to a gap like that between systems programming and web development. It was referring to a gap like that between developing web applications in Ruby or Python. Drop a Django guy into a Rails project or vice versa and they will hit productivity parity within a very short span of time.

The problem that the post laments is that while there absolutely are separate domains within the programming field, HR people rarely have any idea what those domains actually are. Because of this, they tend to operate under the assumption that every single entity (language, framework, etc) is a different domain, and if you haven't worked with the right entity then you don't have enough experience.

Edit: To expand on this a bit further, your example of systems programming vs. web development is actually a perfect example of what the right question would be for the interviewer to ask. Has the carpenter built a lot of houses, or have they built a lot of tables and chairs? What wood they used to build them doesn't matter much, but what they built with it is very important and is where the real domain gaps actually lie. This distinction crosses over to programming very well.

Yeah, that's a terrible analogy.

The appropriate analog for a programming language is a hammer or a screwdriver. The appropriate analog for wood is the processor.

So say the folks who think all wood is interchangeable. For instance, red oak and white oak are more than just differences in color. Someone with experience would know which one to use if one needed more resistance to water and rot (hint: white oak). Some woods are more workable with hand tools, and others machine better. This is the stuff you want someone to know.

I think there is some value in knowing the nuances of a new technology/language/wood. That could be the difference in whether you'll have to redo someone's work because they wanted to start their curly bracket on a new line in your javascript project. Of course, that won't excuse the non-technical HR person who skips your resume because their buzzword isn't listed there.

Terrible analogy.

A better analogy would be to contrast the different styles of carpentry: things with moving parts vs things without them, things on a large scale vs intricate things on a small scale, etc.

I think the fact that this joke has poked a nerve on so many people speaks to how true it is.

I suspect a lot of programmers get so attached to the knowledge they've accumulated, that they start to overvalue it. They assume that no outsider could easily pick up what took them years. But that's not really true -- if you've been around long enough, you start to see patterns, and a lot of things just fall into place. It's like learning a new natural language, the first one is hard, but each successive one becomes easier.

This is funny, but also painful, because I feel like this is me. I've been working on every kind of computer problem I came across for 13 years, and I wasn't thinking about how any of it would look on my resume, and that much work is very hard to summarize.

I think of myself as a guy who can create or improve text files for computers. I think everyone needs this, but nobody wants this. I'm doing a terrible job of selling myself, and it's actually starting to hurt.

If by "text files" you mean source code, then yes, you're selling yourself totally wrong.

Don't sell what you do, sell what your work does. That is, sell the idea of the benefit of your work. Put it in terms of them, not you.

While I agree with the general idea of the analogy (that great programmers are effective, no matter how many specific years of experience they have with language X), it doesn't quite hold up. It would really only be accurate if learning to be effective with brown/walnut/etc. could take several months, as is the case with some programming languages/tools/methodologies.

What is this language you've been using that is so terribly different from what people learned in college that it takes the months to be effective, not even efficient? Off the top of my head, I produce.... prolog and haskell. It's very, very unlikely you'd apply for a job that was looking for those languages without realizing it.

If you know java, you know python, and you know c, and you can think in algorithmic rather than implementation terms, then you're good for pretty much anything. The hard problems are the same everywhere: cache invalidation and naming things. (I'm only partially kidding.)

EDIT: Besides, if you're hiring for 3-5 years, the advantage language knowledge grants candidates becomes minimal, and the ability to apply old lessons, to learn, to adapt, dominates. If someone has issues learning a language, there are probably more striking problems that would prevent them from getting the job anyway.

The two you mention (Haskell and Prolog) are great examples of languages where people can actually have negative impact for a while until they really get up to speed with the language. Pretty much any functional or declarative language fits that bill, and definitely any Lisp. Maybe not 6 months, but definitely at least a couple of months to start contributing a lot of additional value (in addition to getting set up with the team's environment and workflow).

Amazingly, even if someone does learn Java, Python, and C, he or she is not necessarily able to generalize that knowledge to other languages, or even to larger-scale projects in those languages. For example, I wouldn't want to take someone with a lot of Python experience and a semester's worth of C, and put them on a large-scale firmware project or Linux-kernel-hacking project. There are a lot of ways somebody who thinks they know C could mess up a project like that.

In general I agree with you: a truly smart engineer can pick things up as they go, especially on a longer time frame. However, this isn't always the case. Though my perception is admittedly warped a bit working in startups, where you need people to hit the ground running immediately.

Well, you have to remember that very few places uses lisp for that very reason (the benefits don't outweigh the training cost), and the few production bits of lisp code I have seen work like java (albeit less object-oriented) with macros.

Second, I only mentioned C because of its use in understanding computers. Memory management is definitely a skill that people should (but often don't) learn in college, at least to understand what's happening when your GC hits some GC-unfriendly code. So I agree that memory management (via C) is a niche skill, so the analogy outlined in the original post doesn't apply... but quite honestly, how many people on this site write C regularly enough that lack of knowledge of C is going to seriously impede them? The vast majority of jobs I see are for PHP, Python, Java, and C#, at which point the largest impediment is the time it takes to get the O'Reilly book.

I agree that most tools that are similar are fairly easy to switch between: PHP/Python/Ruby/Groovy, and Java/C#/C++, all imperative, OO, etc. Also, from a tools standpoint, Rails guys can use Django and vice versa, pretty much the same, for sure.

It also sounds like you agree that that's not so easily done with (quoting myself from above), "some programming languages/tools/methodologies." So sometimes, sometimes not.

So... we agree? :P

Yes, we agree. :)

please tell me most people aren't this silly when they interview folks.

have the carpenter build something (of trivial scope) while you watch. somewhat analogous to coding on the whiteboard in the interview.

come to think of it, it might be darn hard to interview carpenters. but if you watch them work for 2 hours you know everything.

> please tell me most people aren't this silly when they interview folks.

I would imagine much of the technical side of HN would be considered overqualified for the lowest quartile (completely arbitrary number) of jobs by interview quality... I've never witnessed this either, but I've seen it in tangential ways. The Daily WTF isn't fiction, unfortunately.

Reply on news.ycombinator.com