

If carpenters were hired like programmers (2004) - rmason
http://dawood.in/if-carpenters-were-hired-like-programmers/

======
benjamincburns
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."

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

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

------
davidroberts
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?

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

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

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

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

------
Cogito
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...](http://www.jasonbock.net/jb/Default.aspx?blog=entry.7c334037d1a9437d9fa6506e2f35eaac)

[2]
[http://web.archive.org/web/20130210235908/http://www.jasonbo...](http://web.archive.org/web/20130210235908/http://www.jasonbock.net/jb/Default.aspx?blog=entry.7c334037d1a9437d9fa6506e2f35eaac)

[3] <http://magenic.com/>

[4] From the jasonbock.net post: _Posted at 10.13.2004 11:38:07 AM_

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

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

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

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

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

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

~~~
dylangs1030
How would you have answered differently?

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

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

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

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

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

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

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

------
dkoch
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?

~~~
munin
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?

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

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

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

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

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

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

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

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

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

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

~~~
japiccolo
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

~~~
duaneb
Yes, we agree. :)

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

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

