
If Carpenters Were Hired Like Programmers - adwn
http://www.dawood.in/if-carpenters-were-hired-like-programmers/
======
vog
Original discussion to the original article posted by Jason Bock (which was
merely copied by Dawood Sangameshwari without proper attribution [1]):

[https://news.ycombinator.com/item?id=7819413](https://news.ycombinator.com/item?id=7819413)

[1] There is some attribution a the bottom of the page, but it isn't proper.
It contains neither the original author's name, nor is it a clickable link.
It's just a plain text URL. Better than nothing, but still the most shabby way
of "attribution" I've ever seen.

~~~
frostmatthew
At the top of
[http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...](http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac)
Bock says _I didn 't write this, so I can't take credit for it_ so I'm not
sure failing to include his name or clickable link really qualifies as
"shabby" attribution.

~~~
vog
At least James Bock added a (clickable) link to the closest source he could
find. Dawood Sangameshwari could have taken at least that one.

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

~~~
freshyill
And the real kicker is that no company really gives a shit about anyone. The
expect complete loyalty, but they have none in return.

~~~
jethro_tell
Yeah, that kinda bums me out.

------
lordnacho
This is so true. I see a lot of job ads that seem to require very specific
experience, but where anyone in that field could do the job.

If you just make up eg 4 different types of technology, and put a few things
in each bracket:

[SVN, Git, Mercurial, CVS] [MySQL, PostgreSQL, Oracle, MSSQL] [AMQP, MQTT,
STOMP, RabbitMQ] [Java, C#, C++, ObjC]

Now if someone came along and said they'd solved a domain problem (eg trading
systems) with one of each of those, I would more or less believe they could do
it with any of the others, with a bit of time to get used to things
(particularly c++).

But if you don't believe that, ie if you decide the person must have a
specific combination, then you've just shattered the potential pool of
applicants into 256 little pieces.

The other thing that annoys me is the pettiness of the interview questions. So
many things that you could easily google can be used to stump anyone. What's
the default implementation of GetHash() in c#? I actually got asked this once.

Then there's the other way to do things, which is to do an online coding
assessment. I guess this gets rid of the FizzBuzz failures, but it tends to be
a problem that's too small to see if you're about to dig a hole.

~~~
barrkel
_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, testing if you know the fundamental requirements for objects you might
use as keys in a Dictionary.

The specific number returned and its relationship with the identity of the
object - that's not important, and is truly not something you could be
expected to know. But you're ability to think things through, and know the
environment - yes.

~~~
jhall1468
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#.

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

~~~
DanielBMarkham
Here's my exact train of thought while reading that:

 _GetHash? What the frack? Isn 't that on object somewhere? Right, object
handles all the common copy semantics and so forth. Use the hash to check for
equality; things on the stack instead of the heap, yadda yadda..

Dang, here the guy is going into detail why this is so important. Ah yes,
value versus reference semantics. Boxing and so forth. Tiny trivia around how
the CLR works. I remember those days well. Would make for a great Nerd
Jeopardy question.

But who cares about all of that? I'll look it up if I need it. As far as
memory usage, I worry about that by using pure FP and being careful what kinds
of data structures I use. Problem solved._

Encyclopedic knowledge is great, but the real trick is dumping everything
possible offline and then knowing how and when you should get back to looking
at it.

~~~
eropple
While in the general case I would agree with you and I try very hard to dump
as much stuff offline as possible, I would argue that this is one of those
things you _cannot_ look up "if you need it", similar to the difference
between 'class' and 'struct' in C# or the difference between 'class' and 'case
class' in Scala (the C# one being a runtime implementation difference, the
latter being a fairly large OO design difference). It's something you need to
internalize to do well in the language and the environment.

C# (and similarly Java) are so tightly coupled to their runtime languages
that, personally, I do feel like I need to understand stuff like this at an
intuitive, not-even-thinking-about-it level to be able to write good, fast,
clean code.

~~~
DanielBMarkham
I do not think we disagree.

My point was understanding the stack and heap, boxing and unboxing, were great
to know general purpose knowledge about how type systems are created and used
in modern languages, whether Java or .NET

If you know what it is, and you know why it is important and when it is used,
then any detail you might miss or mangle really isn't that important.

In a similar fashion, I can describe in general terms how a virtual lookup
table is fashioned, and how method signatures work in OO linkers. I'd probably
miss 90% of the details, but I retain enough of an overview to correct myself
when required. I can know something in general terms well enough to know where
to go when I dive deep. That's the goal.

You have to internalize struct and class. Not so much on the relationship
between the built-in hash function and the rest of it. You start using structs
and classes, you start extending the type system, badda boom, badda bing --
you end up in the same place. No need to be able to give a lecture on it. Just
be able to do the work :)

------
DanielBMarkham
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, incomplete, or put together haphazardly. Now stop at one of the houses
where the building crew is still there and watch them spend all day talking
about the nail-o-matic 200psi nailgun or the robot auto-roofer that the
carpenters in the next town are using.

The situation is sad from every angle.

~~~
jerf
A: "Dude, have you seen this Nail-o-Matic 2000 nailgun?"

B: "No. It looks totally awesome, it's so shiny and chrome..."

A: "Yeah, it's the latest thing, I picked it up last night. Let's see how it
does on this roof..."

 _A puts a shingle down and shoots a nail in. The nail rips through the
shingle, blasts a 2-inch diameter hole in the roof and embeds itself firmly
into the floor of the second story._

B: "Whoa, that's AWESOME! Can I try?"

 _BLAM! BLAM! BLAM! BLAM!_

A: "Dude, this ROCKS! Hey, boss!"

C: "Yeah?"

A: "Good news, we're going to finish this job in record time!"

C: "Whoa! Where'd you score a Nail-o-Matic 2000!?! That's _awesome!_ I've
heard all sorts of great things about how powerful it is!"

 _Nail-o-Matic 2000: Because More Power Is Always Better. Always._

~~~
DanielBMarkham
A. You know? What we really should do is get that new Blast-O-Matic bulldozer
I have parked outside and tear all this crap down and start over! I saw a
video on YouTube last night that said if we built houses using silly putty
that they were impermeable to weather!

B. That's a great idea. Does it work with the Nail-o-Matic?

A. I don't see why not. They are both made of atoms.

C. Hang on guys. That's not going to work. What am I thinking?

A. What do you mean?

C. Dude. We have to draw pictures of the house first! I mean without pictures?
We're just throwing stuff together. Our problem all along is that we haven't
drawn enough pictures.

B. So if we draw enough pictures, then can we use the Blast-O-Matic, the Nail-
O-Matic, and the silly putty?

C. Sure! I don't see why not. If we spend enough time drawing diagrams, dang
near anything should be possible. At least on the diagram. Let me just pull
out this circuit diagram for the Pentium CPU and we'll see how it relates to
the average density of silly putty over time...

(B runs out and begins bulldozing house while A and C huddle over a blueprint
with their slide rules)

B. Hey guys! You're doing a great job! Let me know when you're ready. I'll
just go ahead and get started with the bulldozing.

~~~
backlava
So do I understand correctly that in this metaphor the poor quality of
software is mostly because the practitioners are morons? I need to revisit the
creeping complexity in my own projects and try to understand where I used the
wrong nailgun, because this seems like a super productive analogy.

~~~
DanielBMarkham
The joke is that nowhere in this picture is the actual guy who is receiving
value from the work, the guy who keeps saying in survey after survey that our
work sucks -- the guy paying for the house. We distract ourselves by
everything under the sun from the continuous conversation and relationship
management with the value receiver necessary to make sure we're doing
something that the guy writing the check likes.

Sometimes we're distracted in an angry way "Guys! We need to straighten up and
do X!" Sometimes we distract ourselves just because of bright and shiny
objects "Wow! Take a look at that!" Sometimes we quibble over seemingly
insignificant items. Sometimes we take things that should be important and
elevate them to the highest level possible.

But the overall pattern is clear. We want to do anything and everything --
except be joined at the hip into the value stream, which is exactly what our
job is.

This was the hard lesson that startups taught me: lots of stuff can be neat,
valuable, or worth consideration. But a true professional knows that whatever
he is doing, he is doing for another human being - and so he seeks to befriend
that person, have a trustworthy relationship, and look out after that person's
best interests.

That's not nearly as much fun as flipping bits, and it deals with a lot of
messy social and human things.

------
henrik_w
"Well, I’m a carpenter, so I’ve worked with all kinds of wood, you know, and
there are some differences, but I think if you’re a good carpenter …"

In my experience, a good programmer in one language is very likely a good
programmer in another language as well. There are a lot more commonalities
than some people realize. That's the reason why I'm sceptical of claims such
as "the programmer knowledge half-life is X years".

More in "Programmer Knowledge" [http://henrikwarne.com/2014/12/15/programmer-
knowledge/](http://henrikwarne.com/2014/12/15/programmer-knowledge/)

~~~
seanwilson
I'd rather hire a programmer that knew many languages than one who only knew
one language really well though. Once you've learned a few frameworks and
languages, you get much better at picking up new ones quickly because you've
seen the same concepts somewhere else already.

~~~
weixiyen
I've always gone for the ones who really knew one language inside and out. The
reason is actually very simple, they have demonstrated exceptional skill to
dive deep into one language, so they should be able to do the same in another
language.

The jack-of-all-trades people usually are much riskier hires as they don't
always understand how deep they can go in any particular language, thus are
unable to fully assess what they don't know, and require much more guidance as
a result.

~~~
vinceguidry
That's how I find myself conducting my own personal development. The deeper I
dive into Ruby, the more I find myself able to hold my own in conversation
with my friend the graybeard C++ guy whose been doing it longer than I've been
alive. He'll describe something he's trying to do and I'll be able to
immediately find an analogue in Ruby. I'll get a sense for how Ruby exists in
the general evolution of programming languages and what it tries to solve. The
experience makes me more aware of the problems that Ruby tries to solve so
that I can use it better.

I see a lot of people who know three or four languages, but don't understand
any of them really well or the underlying concepts. Or they'll focus over-
heavily on the algorithmic side of the craft and neglect maintainability and
readability. I see a lot of Ruby that looks like C.

When I finally do start branching out and learning new languages, it will be
on a totally different level. I'll be diving into the entire ecosystem of the
language and not just struggling at the surface.

But before that, I want to learn how Rails really works. I think I understand
the difference between a library and an application, now I want to understand
what a framework is and how one is built and maintained.

~~~
barrkel
_now I want to understand what a framework is_

I'll short-circuit that one for you right now: you call a library, a framework
calls you - it figures out how by some combination of convention and
configuration. Libraries put you in control, frameworks make you cede control.
You can usually mix and match libraries, whereas you can only use one
framework at a time comfortably.

~~~
vinceguidry
So is jQuery a library or a framework? I've seen it called, and used, both
ways. It's not a hard and fast definition, and that's what I mean by "really
understanding" something. I want the things I build to be able to be used in
any way that it would be useful. It's the fractal landscape at the boundary
between the definitions that I'm interested in.

I find myself refactoring code a lot, pulling pieces out and putting them
elsewhere. Sometimes I think, "this piece would be better as a gem", or that
"this gem needs to be its own application.

When I think about the overall thrust of what I'm doing, I get the sense that
I'm building a framework. I need to be able to work web applications into the
framework, and the only framework worth really using in this fashion is Rails.
But Rails isn't intended to be included as you would a library. I need to
understand it better if I'm going to be able to work it into my own framework.

~~~
falcolas
I believe that jQuery is neither - it's a collection of tools to assist with
programming webpages in whichever paradigm is appropriate for that particular
task.

This approach gives the advantage of ceding ultimate control back to the
programmer, at the cost of some internal inconsistency.

~~~
vinceguidry
That's an interesting view. I can't think of jQuery as a tool. I have a
collection of tools I use, I find a tool to be quite different from an
application, a library, or a framework. Sublime Text is one of my tools. So is
git. I also consider Ruby a tool. My laptop is a tool. I have some git-x
commands that I've been slowly building on that I use collectively as a tool.

To me a tool is an extension of one's mind or body that goes into all projects
that you work on. I can give away an application or a library. I can't give
away a tool, or at least, it wouldn't really make sense to. I want to use all
my tools to build a project, all my projects to use the same tools. That's why
I stick to Ruby rather than bouncing around. I use Coffeescript/jQuery on web
projects but I consider it a kludge, though not as much of a kludge as using
Opal would be. I'd want Ruby integrated tightly into the browser before I'd
prefer it over Javascript. I don't mind Coffeescript because I find that if
you stick to a certain convention, Coffeescript is as easy to maintain as
Javascript and I prefer the terser syntax.

My ultimate goal would be to be able to hack on all my tools like I hack
applications. For example, I'd love to be able to replace Sublime Text with
redcar, an editor written in Ruby, I've taken baby steps in that direction
with my git scripts. I haven't decided if it would be better to write my own
editor though. I'm probably at least a few years from that being able to
integrate that into my workflow.

------
aw3c2
Stolen from
[http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...](http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac)

~~~
mtmail
The source is listed at the end of the joke so at least there was some
attribution.

~~~
mathgeek
I find that in this age of no one reading past the inferred end of the
article, it's best to put attribution at the top so as to avoid this very
confusion. Just my two pennies.

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

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

~~~
spiralpolitik
Which would be perfectly valid if software developers spent their entire day
solving problems on the whiteboard. But we don't.

~~~
frostmatthew
Imagine you were in charge of casting for your community theater's production
of _Hamlet_. How would you decide who to cast?

I'm guessing you would find it sensible to hold auditions. Does an audition
perfectly mimic what they would actually spend their time doing come showtime?
No. There isn't an audience, the lighting and acoustics are different, nobody
is wearing costumes, everyone is standing in the same place instead of moving
around, people are reading from scripts instead of having lines memorized,
etc.

The audition isn't intended to mirror a performance - it's intended to give
some insight into how someone may perform. Likewise, whiteboarding isn't
intended to replicate a typical day in the life of a software developer. It's
intended to give a glimpse into how you solve problems.

As I said above, it's not perfect, but it's far more useful than hiring
someone _without_ any coding exercises and basing your decision just on how
well they answer questions or what their background is. In fact the whole
point of the post you're commenting on is to point out the foolishness of
basing hiring decisions solely on having X years of experience in Y
technology.

~~~
mtviewdave
>As I said above, it's not perfect, but it's far more useful than hiring
someone without any coding exercises

Whiteboarding vs no coding exercises is a false dichotomy. There are ways to
test coding in a 45 minute interview that don't involve standing in front of a
whiteboard, writing with a marker.

~~~
frostmatthew
> Whiteboarding vs no coding exercises is a false dichotomy.

Sorry, it wasn't my intention to suggest those were the only two options (I
was attempting to comment on the benefits of coding exercises, regardless of
method).

Using a computer is certainly as good or better than a whiteboard. Though one
of the bigger downsides to using a computer is there's generally this
expectation you need to write "real" code that actually compiles and runs and
so the focus becomes as much on writing syntactically correct code as about
how you solve the problem (when only the latter has value).

------
fivedogit
I like the metaphor and style, but I think he left some good parts out. Such
as (and yes I was asked these):

\- The ridiculously broad yes or no honor question (e.g. "So are you familiar
with data structures and design patterns?”)

\- The ridiculously specific-to-the-company question (e.g. " Here is a batch
of the data our systems generate. How would you process it for triggering of
requests to our api?")

\- The vaguely worded trick question: "OK that looks good... But how would you
do it if you didn't have all these nice Java objects and methods?")

\- The Prove-it Take-home that doesn't change anything. "We use ruby and
you've mostly used Java, do this ruby take home assignment." Two days later.
"Your assignment looks great but we're really looking for someone with more
Ruby experience."

\- The post-coding interview, resume-based rejection AKA "why the fuck did you
ask me to come in in the first place?" rejection. (E.g. "Your coding interview
went well but you've jumped around to different projects and we're not sure
you wouldn't leave us if given the chance.")

\- The didn't drink enough kool-aid rejection. "Don't know the CEO's full bio?
Don't know the intricate details of our public API? Didn't read our blog post
from this morning? For shame."

------
V-2
This answer on Programmers Stack Exchange sums the problem up very nicely:

[http://programmers.stackexchange.com/a/1847](http://programmers.stackexchange.com/a/1847)

> A common HR thing that drives me nuts when I'm job hunting: the implicit
> assumption that all coding skills are language-specific, that there is no
> software engineering expertise that transcends command sets. That ten years
> experience in Java and another five in Perl mean you'd be completely useless
> on a project that uses, say, C#.

> "Yes, there's a learning curve. But I've made harder transitions than this.
> I'll make you a deal, pay me 80% for the first month and at the end of that
> time if I'm not ... oh, wait, we're not actually having this conversation,
> because your HR monkey simply deleted my application."

~~~
derekp7
I think that's why a lot of companies are now doing contract-to-hire. First
they let the contracting agency do the pre-screening, and if the employee
doesn't work out the contract just doesn't get renewed.

Only problem is for the employee -- it is difficult during the contract phase,
if they don't get any feedback if they will be converted to an FTE, and the
lack of benefits. So for the hiring company, they will no be able to steal
away any good developers who are currently fully employed.

------
stillsut
This actually will happen if you speak with an HR rep for insurance predictive
modelling:

-So do you have experience with SAS?

-Yes, but mostly I model in R. They are sister languages.

-So how much SAS, how much R?

-Mostly R as it is widely held to be a superior language

-But SAS you can do more with!

-Ahh, if Big-Famous-Tech-Company-X wanted to do stat modelling they use R, not SAS. Again, anyone who does statistical modelling knows this.

-But we pay for SAS

-Yeah, sorry about that...

~~~
italophil
If they want SAS that is their choice.

It's like asking a carpenter to built a cupboard and he answers: "I'd rather
build a shelf, it will hold your dishes just as well."

~~~
wtbob
No, it's more like asking a carpenter to build a cupboard, but when he brings
a hammer to the worksite you ask him to use a rubber mallet instead. Sure, one
_could_ drive nails with a rubber mallet—but who'd want to?

Likewise, who would want to use an inferior language or library when superior
ones exist?

~~~
omegaham
> Likewise, who would want to use an inferior language or library when
> superior ones exist?

My guess is that the existing codebase is in inferiorLanguage, and it would be
a massive pain in the ass to rewrite it in superiorLanguage.

The carpentry analogy doesn't really work here because you can stop using the
rubber mallet at any time. You can't just switch frameworks or languages when
you feel like it.

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

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

~~~
vonmoltke
That is a serious flaw in the typical interview process. An interview is
supposed to screen people based on whether or not they can do actual work. If
you are really screening for some parallel skill, then your hires are going to
be a crapshoot.

------
sjclemmy
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 very specific set of requirements for very
specific reasons. The company is .net all the way and has a couple of
permanent developers who know only VB and have no C# experience. Because of a
large influx of work, these developers needed some additional resource for a
short period of time. I wanted to try and increase the skill level of the
permanent developers as they are not very familiar with design patterns and
'modern' techniques. To this end, I wanted C# developers with familiarity with
design patterns and modern best practice to come in and develop in VB. I
didn't care if they hadn't used VB recently at all. But I did care that they
knew .net. I don't have time for them to learn .net. So I can't have someone
from the Java world, it would just take too long. But at the same time, I'd
rather not have a VB only person, as they tend (and I am generalising, I know)
to not understand much about design patterns and they don't tend to have broad
programming knowledge.

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.

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

~~~
andkon
This is a really, really cool idea. I think the danger with BPA is that if
you're hiring them way too early (like... a year before they'd be firing on
all cylinders), then you risk them disengaging and churning out. NFL teams
have a constant amount and kind of work that's predictable every season that
prevents them from misallocating investments like this - and prevents players
from misallocating their labour. Software teams, on the other hand, risk
building the wrong thing, and hiring people for problems that won't come about
until they build the right thing. Which usually means that those people get
antsy (I definitely had this experience, but in a marketing role, which is
even more stage-dependent than working dev positions, so I'm probably a little
more sensitive to the chance and impact of being hired too early).

~~~
jasonwocky
This sounds reasonable, though if you hire the Best-Programmer-Available
regardless of the presence of a specific technical skill, I'd be surprised if
they really take a year to get firing on all cylinders. Maybe a month or two
at most would be what I would expect in the sorts of places I've worked.

Sure, some places (especially in startup land) can't even afford to wait even
a month, but that doesn't make the dynamic any less of an antipattern. Instead
it's just one of the painful tradeoffs people make while they need to manage
their runway extra closely.

------
stared
Then it means that you are applying to a wrong company (already consumed by
bureaucracy, with little tech value or understanding)...

I remember my programming interviews as the most meritocratic ones (much more
than e.g. in academia, where there is a problem that one is have too low high,
or different official credentials).

------
tokenadult
To all my friends here on Hacker News: Over a few years, I prepared a FAQ
document on company hiring procedures for questions that come up here on
Hacker News all the time about legal and effective hiring procedures. Most
companies use lousy procedures for hiring workers, and that throws away
competitive advantage. There is an optimal way to hire, and a century of
research on what it is. Rather than repeat all my previous keystrokes here,
I'll just link[1] to an earlier version of the FAQ. If you don't want even to
follow a link to a very popular comment, let me just pass on here the summary
of the FAQ:

EXECUTIVE SUMMARY: If you are hiring for any kind of job in the United States,
prefer a work-sample test as your hiring procedure. If you are hiring in most
other parts of the world, use a work-sample test in combination with a general
mental ability test.

[1]
[https://news.ycombinator.com/item?id=4613543](https://news.ycombinator.com/item?id=4613543)

I'm happy to answer follow-up questions about this. It's better for companies
and it's better for capable workers for companies to learn how to hire
smarter.

------
nstart
Last June I started work with a software engineering company that was using
meteorjs heavily for their new product and php and java for their main
product. Front end was standard jquery. At the time of joining, I had only
ever used java, and that too in university for a project on multi
threading/parallel processing. In about half a month I was acquainted with the
basics of meteor and node js, and within a month I was completely up to speed
with the intricacies of the development enivronment. (not all of them. By up
to speed I mean, I had figured out where to look when I hit a gotcha). This
included mongo db which I had never used till I joined.

I then shifted time to working both on the new product and the backend of
their old product. I was using PHP and a framework (I can't remember which
one) that I had never touched before. Took me about a week and a half to get
up to speed before starting to work on the actual product.

This isn't some display of talent. I believe that any engineer who understands
the fundamentals would do exactly what I did. (Provided they are willing to
read documentation without skimming through it).

The point here is, I left that company in October. And they've just reopened
the position I left vacant. Looking at the list of qualifications and
experience required on that list, I couldn't help but think, I would have
never thought myself adequate for the job if I had looked at the ad posted
since I had never touched any of the stuff they required. Turned out, when it
actually comes down to it, it really doesn't matter.

This analogy is actually spot on. Languages really do become another shade of
paint at some point. And I never really believed in that till a couple of
weeks ago when I saw that job posting. Pretty crazy that as an industry we
still believe in this kind of hiring process.

~~~
programmernews3
I think you have a great point, although some people are able to do what you
did and some are not. Even if some people can do fast just-in-time learning
there is value in expertise of the sort described in [0].

[0] [http://norvig.com/21-days.html](http://norvig.com/21-days.html)

------
belorn
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 other hand is not liable for anything. If it breaks or leaks
information at the easiest provocation, then its not the programmer who might
loose money. All risk is put on the employer or customer, and as such, it
becomes their responsibility to identify and test a programmer before spending
money. As a result, you get questions which are mostly irrelevant to the task
at hand, but which might sorts out high risk vs low risk.

If I hired a carpenter under those conditions, I would ask what brand of paint
they buy. If its an expensive one, it might hint towards a professional.

~~~
sopooneo
Your logic makes sense, but it seems like every high school I've ever been in
or heard about that had just recently been built leaked rain like a sieve.

~~~
Spooky23
That's because of flawed design usually. Architects cook up these lovely
stylish renderings that the school boards find inspiring (particularly since
it isn't their cash), which often involve flat or complex roofs.

Fast forward to the post-construction era, and that inspiring building now has
10 inches of water or ice on the roof. Water being water, it eventually gets
in, usually around flashing.

------
bmoresbest55
I really enjoyed the post. I reminded me a lot of this Youtube
video([http://youtu.be/BKorP55Aqvg](http://youtu.be/BKorP55Aqvg)).

I understand this is a comical post but as the son of a carpenter and
understanding the profession decently well I would say these are none of the
questions that would be asked of a carpenter.

There are however many important questions a person would need to answer to be
hired as a carpenter or more likely be able to join a union. There they would
be able to get experience and training. Then the company the union carpenter
work for already knows the skills and abilities they have and there is really
no need for any interview. Any GC or sub asks for guys to do a job. The local
sends them the qualified guys. Pretty simple actually.

~~~
delinka
"...these are none of the questions that would be asked of a carpenter."

That's exactly the point. But it parallels the useless questions so often
asked of the general computer programmer by the Corporate HR Recruiter Drone .

------
pargon
They forgot to ask about the deeply theoretical questions that the carpenter
wouldn't actually use at the job.

"Now could you whiteboard for me how a table saw is built?"

"I've never had to build a table saw."

"I just want to see how you think."

------
linker3000
...and architects sometimes have to go to great lengths before they are
allowed to work on your castle:

[http://www.fotolibra.com/gallery/698061/hiorne-tower-nr-
arun...](http://www.fotolibra.com/gallery/698061/hiorne-tower-nr-arundel-west-
sussex/)

...and for sci fi fans who think the Tower looks familiar:

[http://www.doctorwholocations.net/locations/arundelparktower](http://www.doctorwholocations.net/locations/arundelparktower)

------
blueatlas
I came across this [1] job posting last week. Made me realize how ridiculous
the knowledge and experience expected of a web developer has become. I
particularly like bullet 6, "Team-oriented, flexible, and able to work in an
ambiguous and/or changing work environment." Really?

[1]
[http://jobs.hbispace.com/web/95148/job_2-15.html?cacheBuster...](http://jobs.hbispace.com/web/95148/job_2-15.html?cacheBuster=6420099)

~~~
mtbcoder
DHTML? I haven't heard that term used in a while. I think can translate that
job posting as such: "In order to save costs, we've trimmed all developer
positions except one. You will be the sole developer responsible for
everything we do. You will always need to be on-call to work, even if it's
formatting a Wordpress post for an editor on a Saturday night. You will work
long hours but we'll only pay for 40/week, no overtime. Your salary will be
peanuts and will not cover the cost of living in Washington, DC. Be a team
player and join us."

------
_justin
I have read this before, and I see the source is attributed. If so, why is
this link on HN and not the original. Seems a way to gather some page hits.

------
JayInt
I think it's a really compelling and quite funny article but to actually make
a difference you need the translation. You need the side-by-side comparison
and I think people would sit up and go 'ah' and it will change hiring for
them.

Can someone write this with the real-world situation so 'brown' isn't a guess
at [framework/language/methodology]

------
je42
Depending on the job; i find the deeper somebody knows his/her special field
the better he/she can adapt to another field.

I.e. if you really know the ins/outs of the Java, the VM, changes of the
language over time. You will be able to pick up C#, python f.e.

------
placebo
Love it :) Sad thing is that it hit the nail on the head so accurately (pardon
the pun)

~~~
mathgeek
You really rocked it there.

~~~
Demiurge
Very piercing commentary.

------
hmottestad
Seems like this is the original:
[http://www.jasonbock.net/jb/Default.aspx?blog=entry.7c334037...](http://www.jasonbock.net/jb/Default.aspx?blog=entry.7c334037d1a9437d9fa6506e2f35eaac)

~~~
frostmatthew
How can it be "the original" when it states in the opening paragraph _I didn
't write this, so I can't take credit for it_?

------
whybroke
Given that both articles on that site were swiped from elsewhere without
attribution, perhaps that particular "carpenter" should be asked about theft.

(well ok, one does mention a link to a 404 error)

------
utxaa
of course, this happens, but when it happens just end the interview.

would you like to work in such a place?

------
brickmort
ouch! As someone who's been on an 8-month long job hunt, this hits too close
to home.

------
Throwaway1224
No mention of H1Bs in this hiring related post?

------
mlamat
I will attach this to my resume.

------
pamparosendo
Just great!

------
illumen
Gold.

~~~
robobro
I find it a bit less shiny every time I see it.

