Recruitment and the art of flawed analogy

This blog post is more than 4 years old, so the content may be out of date.

It's becoming a regular theme: "If XXX Were Hired Like Programmers".

Here's a snippet from If Carpenters Were Hired Like Programmers:

Interviewer: So, you're a carpenter, are you?
Carpenter: That's right, that's what I do.

Interviewer: How long have you been doing it?
Carpenter: Ten years.

Interviewer: Great, that's good. Now, I have a few technical questions to ask you to see if you're a fit for our team. OK?
Carpenter: Sure, that'd be fine.

Interviewer: First of all, we're working in a subdivision building a lot of brown houses. Have you built a lot of brown houses before?
Carpenter: Well, I'm a carpenter, so I build houses, and people pretty much paint them the way they want.

Interviewer: Yes, I understand that, but can you give me an idea of how much experience you have with brown? Roughly.
Carpenter: Gosh, I really don't know. Once they're built I don't care what color they get painted. Maybe six months?

Interviewer: Six months? Well, we were looking for someone with a lot more brown experience, but let me ask you some more questions.
Carpenter: Well, OK, but paint is paint, you know.

Interviewer: Yes, well. What about walnut?
Carpenter: What about it?

Interviewer: Have you worked much with walnut?
Carpenter: Sure, walnut, pine, oak, mahogony -- you name it.

Interviewer: But how many years of walnut do you have?
Carpenter: Gosh, I really don't know -- was I supposed to be counting the walnut?

Interviewer: Well, estimate for me.
Carpenter: OK, I'd say I have a year and a half of walnut.

And What if Cars Were Rented Like We Hire Programmers?:

Applicant : I drive a 2008 Subaru.
Agency : That's a shame. We don't have a Subaru to rent you.
Applicant : That's OK. Any car will do.
Agency : No, we can only take on clients who know how to drive the cars we stock. We find it's safer that way. There are so many little differences between cars, we just don't want to take a chance.
Applicant : I have a drivers license. I know how to drive. I've been driving all kinds of cars for 15 years, I am sure I can adapt.
Agency : We appreciate your position, but we can only take exact matches. Otherwise, how could we ever know if you could drive one of our cars?
Applicant : Oookay. I've driven a Taurus before. You probably rent those, don't you?
Agency : Indeed we do. What year did you drive?
Applicant : It was 2009...but I don't see how that ma...
Agency : Oh sorry, we use the 2012 model. We can't possibly let you drive a later model.
Applicant : But, but they aren't that different. Surely if I can drive a 2009 I can drive a 2012?
Agency : Sorry, sir. Our requirements clearly spell out that you must be able to drive a 2012 model.

All these posts are basically promoting the assertion that if you can program, you can program anything. These analogies are flawed.

First of all, cars: sure, licences don't differentiate between a Peugeot 206 and a Subaru Impreza, but most European countries have a fundamental distinction between manual and automatic gearboxes. If you pass your driving test in an automatic, you are not licenced to drive a car with a manual gearbox. And then there's licencing for different vehicle types: cars, motorbikes, trucks, buses, and so on.

Take it one step further and look at airplanes…a standard licence will qualify you to fly a range of very basic single-engine planes. Those planes all have very similar, very basic controls and capabilities. When you look at commercial aircraft though, you need type-specific qualifications. You might be licenced to fly a Boeing 737, but that doesn't qualify you to fly an Airbus A380. It doesn't even qualify you to fly a Boeing 747.

Or take medical staff. Would you want a cardiac surgeon doing your neurosurgery op?

Programming is a technical, specialist skill, and it's perfectly normal to expect senior roles to have previous specialist experience in a particular framework or tool. And it's important for us as a tech community to recognise that, and understand how that will affect our projects and our businesses.

It's generally true that a good developer's main skill is problem-solving, and a good developer will generally be able to pick up a new framework or language fairly easily. But a good developer in framework X will probably not be able to join a project and hit the ground running in framework Y. They will usually need support, co-workers who are more knowledgeable in that framework, and time. How much time? Six months to a year isn't an unreasonably short time, even for an otherwise expert developer.

There are naturally exceptions. If a company is recruiting for a junior role, specialist knowledge probably matters a lot less. If a company is recruiting for a long-term permanent position, they can often afford the time for a great developer to learn a new speciality. So for some roles, it's unimportant, but it's not an unreasonable point to discuss. And technical development is neither carpentry, nor hiring a car, nor any of the other many flawed analogies.

Blog tags:

Comments

Your criticism is flawed because this blog post was in reference to things like framework knowledge, and the thing about frameworks is that it is a lot less useful to remember dictionary-style references to these types of constructs than to understand the concept of how a good one works. The analogy is pointing out that the skill of a programmer is not necessarily based on their experience with cherry vs oak (ie. one API vs another) but how much they have dealt with wood (ie. understanding the concepts of a RESTful framework). A good question would have been "how much have you dealt with wood vs brick" or even more specifically "describe the process of painting the inside of a house" versus pedantic differences in the particulars of any one framework.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <apache>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo]. PHP source code can also be enclosed in <?php ... ?> or <% ... %>.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.