The old “What if they hired carpenters they way they hire programmers?” joke/commentary didn’t sit right with me the first time I read it, and after stumbling across it again I now see why. Among other things:

It’s a complaint without a solution.

I’ve never met anyone in the software industry who is happy with the hiring process, and that includes everyone who’s designed the process. Nobody seems to have a solution to separating the potential stars from the mehs, and anyone who claims they do either doesn’t have enough perspective to understand the difficulty of the problem (young interviewers who have been trained in one particular hiring style seem to be blessed with the arrogance of blind faith), or they’ve perfected the art of hiring the mediocre (a sufficiently rigorous process can probably rule out almost all the disastrous hires, but will likely also lose a few stars…and it’s finding the stars that is the problem).

Pouting that interviews suck without suggesting any improvements is just childish, and doubly so if you’re complaining not about the bizarre “puzzle question” or “culture fit” interviews, but about being questioned on knowledge and experience. Technical interviews can be annoying and they can be done badly, but I’d still much rather work in an industry that does tech interviews than one forced to rely solely on CV reviews and personality-driven poking at “soft skills”.

Engineers aren’t carpenters.

There’s always a terrific slight of hand going on when software developers try to draw analogies to other fields. Blue-collar credentials and being treated like a unique, creative, and highly-paid professional just aren’t compatible. “Programmers” are the architects and structural engineers who design the buildings; they get programming languages and frameworks and IDEs to hammer the nails. I have no doubt that the industry is full of coders banging out one CRUD app after another, but their work bears a lot more relation to architects customizing a house design to a particular site (or, a better analogy, 19th-century railroad engineers applying the standard truss designs to design bridge after bridge) than it does to contractors framing house after house based on the designs they’re handed. The exceptions—coders who really want nothing more than to follow some formula and take no responsibility for the result—are exactly who interviewers are trying to weed out.

It’s disrespectful to carpenters.

Of course, there are carpenters who are creative craftsmen of the first order. Those aren’t the guys you’re going to bend over backwards to hire to frame your walls. The whole story seems to be built on the premise that the only skill a carpenter has is the ability to drive a nail straight, making any notion of an “interview” farcical. (Returning the first point, I suppose the implication is that driving a nail is the fizzbuzz of carpentry.)

The interviewee is worse than the interviewer.

Let’s just cover the first few questions:

So, you’re a carpenter, are you? How long have you been doing it?

If the only way you can describe your work is “I’m a programmer. For ten years now.” then I just don’t believe you. Yes it would be friendlier if the interviewer led a bit with “What kind of work have you been doing?” or “Tell me about some of your favorite projects.” but you’ve got to meet a weak interviewer in the middle. The main premise of this complaint about programming interviews is that a programmer is a programmer is a programmer, and the details don’t matter, and that’s straight-up bullshit. Have you worked on high-performance systems? Distributed applications? User interfaces? Large-scale software? There’s a hell of a difference between a framer, a cabinet-maker, and a furniture-maker. As an interviewer I’m open to the idea that someone good at any one of these probably has great potential for any of the others, but if you’ve got nothing more to say about your career than that you’ve done general things in a general sort of way, you can’t exactly blame me for taking my own direction on what details I’m going to dig into.

First of all, we’re working in a subdivision building a lot of brown houses. Have you built a lot of brown houses before?

I don’t see a lot of brown paint in the world. Some, but not much. There is, however, a lot of brown stain, and brown shingling, and brown brick. And all those kinds of brown would seem to be of major interest to a carpenter: if something is being stained instead of painted then I’d think that would affect the choice of wood. Maybe even how it’s joined. I don’t know; I’m not a carpenter.

Questions like this are exactly how a good interviewer separates a blinkered newbie from an expert with perspective. If you’re building a software library that will be called by a UI, then responsiveness matters. If you’re writing an order processing system open to the public, then you need to consider denial-of-service issues. If the overall software system will be distributed, then the architecture needs to take rollout into consideration. Shrugging off context is only a professional qualification for field-goal kickers.

What about walnut? Have you worked much with walnut?

In this hypothetical, we’re talking about a job building houses. Houses are most commonly built using platform framing of stud walls made from spruce, pine, or fir. Soft woods. Relatively cheap. Walnut is an expensive hard wood. I don’t think it’s used much (if at all) for stud wall construction, but it is occasionally used for post-and-beam construction, which involves either metal brackets or traditional cut joinery, and for nonstructural finishings. Any real carpenter would know the differences between varieties of wood, between the two major types of wood construction, and between the different roles wood can play in a project. And he’d definitely know which projects he’d worked on that involved which.

If a programmer walked into an interview and gave answers this evasive about how many projects he’d done in Java, he’d be an obvious no-hire. Not having certain experience is one thing; not even knowing what experience you have is another matter entirely. We can argue about the extent to which an employer should balance hiring for existing skills and hiring for potential to learn, but you can’t claim the latter unless you can point to prior success at learning new skills.

The punchline is not a joke.

The punchline is that the interviewer hires a car salesman who’d sold brown cars with walnut interiors. I’m with the interviewer on this one. Our hypothetical carpenter was effectively arguing that even if he’d only ever hammered together pine stud walls he could easily learn to do finish carpentry with walnut for a client very particular about his browns. If learning this stuff is so easy, then I’d rather hire someone who understands what the goal is of finish carpentry. And ideally someone who showed some interest in the project and the skills required to do it, not just the job.

The whole anecdote smacks of entitlement.

Given all of the above, the true subtext of this “joke” is that calling yourself a programmer entitles you to a job. But the really galling part is that the “calling yourself a programmer” bit needn’t even require relevant programming skills or experience. It’s effectively a declaration that “programmers” are a different class of people in possession of some unquantifiable gift, and it’s beneath them to justify their value.

It’s “I’m smart; pay me” brattiness.