
What If Cars Were Rented Like We Hire Programmers? - carlos
http://highscalability.com/blog/2013/1/16/what-if-cars-were-rented-like-we-hire-programmers.html
======
Hovertruck
This analogy is backwards... Hiring a programmer is an exchange of company
money (or equity, benefits, etc) for a service (programming skills). Renting a
car is an exchange of one's own money for a service (use of the car).

In this case, the person renting the car would be "interviewing" the car
rental company to determine if their service is worth their money.

~~~
arscan
>> In this case, the person renting the car would be "interviewing" the car
rental company to determine if their service is worth their money.

It goes both ways... the rental car agency interviews the person to make sure
she is trustworthy of driving the car. The author is asking you to think about
the relationship a little more abstractly than simply who is giving money to
whom.

Having said, that, I think this is a poor analogy because I don't find it
particularly illuminating and the situations just don't seem very...
analogous.

~~~
bentcorner
Something like "if interviewing carpenters was like interviewing programmers"
would work, with various questions regarding trivia about the Mightyman Bansaw
3000, specific experience using square-faced carbon tipped reverse-threaded
screws and comparisons between building red versus white cabinets.

~~~
Jtsummers
[http://www.jasonbock.net/jb/Default.aspx?blog=entry.7c334037...](http://www.jasonbock.net/jb/Default.aspx?blog=entry.7c334037d1a9437d9fa6506e2f35eaac)

If Carpenters Were Hired Like Programmers

------
rosser
Maybe it's because I just made the egregious mistake of getting drawn into a
gun-control debate with a friend and his friends on Facebook, but hyperbolic
arguments by analogy feel really silly, cheap, and disingenuous to me right
now...

~~~
ProblemFactory
I find that analogies are a poor argumentation technique overall, even if they
are not hyperbolic. It's always possible to find similarities between wildly
different and even opposing ideas. The details matter.

~~~
RegEx
I find analogies very good for explaining concepts (to make the details easier
to understand), but absolutely horrible for debates. Analogies generally over
simplify issues, and hackers are particularly bad at arguing the analogy to an
absurd extent instead of arguing the main premise behind it. It happens here
all the time.

~~~
gknoy
It seems like this example helps highlight the absurdity of requiring
experience in $Language for $Years (or other similar too-constrained metrics)
when an Able Programmer can just learn that stuff. The general populace views
what we do as magic, but understands being able to drive very well. This
effectively says that programming is a general skill, and that a good
programmer should be able to learn it if they already know something similar.
So, your Visual Studio 2012-only shop can hire people w/ 15 years of embedded
C experience, and probably get a pretty solid programmer.

We all seem to consider this as true about being a Good Programmer ("Sure, I
can learn $language_that_you_use"), but are frustrated by HR departments who
don't realize it.

~~~
smsm42
For hiring Excellent Programmer, it is true. For hiring Average Programmer,
experience matters a lot - average programmers become proficient slower than
excellent ones, so it is better to hire somebody that has already passed most
of the learning curve. OTOH, hiring by tool usually doesn't make any sense
unless this tool has really steep learning curve (in which case why use it
anyway? yes, I know there are exceptions, but generally it's true).

------
tzz

      Interviewer#3: How long you been driving your 2010 Escort?
      Applicant:     About 3 years.
      Interviewer#3: Sorry, but we are looking for someone with 
                     experience of driving 2010 Escort for at 
                     least 10 years.

~~~
orangethirty
Ha!

To add:

    
    
        Interviewer#3: We are looking for someone who knows how 
        operate the navigation screen on the 2010 Escort.
        Applicant: My car does not have the navigation option  
        installed.
        Interviewer: Then you do not qualify. Knowing how to 
        work the navigation system is a priority.
        Applicant: I know how to work navigation systems in
        general. My car before this one had a navigation system 
        and I learned it pretty quickly.
        Interviewer#3: No. We need people with 10 years of
        experience with the actual navigation system on the 2010
        Escort. 
    

Note: Ford no longer sells the Escort in the USA. They sell the Focus and the
Fiesta. Both terrific little cars.

~~~
amputect
Interviewer#3: We are willing to accept 8 years of education with a Master's
or equivalent on the subject of 2010 Escort navigation systems in lieu of 10
years driving experience, for otherwise qualified candidates

Completely off-topic response to your note, but I loved my 2000 Focus and I
was almost sad to sell it. It went through air intake hoses on the
transmission about as fast as it did gasoline (hyperbole, but the Arizona heat
was hell on that little rubber elbow. Fixing it took 5 minutes and cost $3
once a year, though, so as far as chronic car problems went it was pretty
mild). It was still running strong after 12 years, and got my wife from Tucson
to Seattle as safe as could be :3

~~~
lancewiggs
> got my wife from Tucson to Seattle as safe as could be It's a lot safer, I
> would have thought, per mile to do long highway drives than lots of short
> urban journeys, particularly on the separated highways in the USA.

~~~
ZoFreX
Yup, the per-mile risk is higher on short journeys.

(Also you might want to edit your comment, it's ended up all on one line)

------
ssharp
My own personal, small sample size experience has shown that if I start
questioning things early on in the interview, I can predict fairly well
whether or not the company will be a good fit or not. I try not to jump to
conclusions but even initial emails and phone calls can make for pretty strong
clues.

If I sense during an interview that things aren't going to be a good fit, I
still try and finish the interview graciously. There is no use burning any
bridge, even if it's one you're 100% certain you'll never use. One trick I do
to keep myself from seeming aloof or displeased is to start asking questions
about the industry. At this point, I know I don't want the job and probably
don't care about the culture, but learning something about an industry you may
not know much about could be useful down the line.

------
dlss
This part was golden:

Agency : How much did you pay for your last rental car?

Applicant : I don't see how that matters. What are you charging?

Agency : We like to know what you paid before so you get a fair rate.

Applicant : I paid market rates.

Agency : Sorry, we must know how much...

~~~
smsm42
Well, if you buy instead of rent, especially used car, that's what 99.99% of
salesmen would do. "How much is that car?" - "well, how much can you pay?"
They have sometimes prices posted but everybody knows these have little
meaning except generic signal of "we consider it an expensive car" or "this
one is cheap".

~~~
droidist2
True. Negotiation 101: the first person to say a number loses.

------
daenz
I've had a few interviews like this.

For future interviews, I've collected similar questions to ask of them
(questions that I have conveniently worked out or looked up the answer to
beforehand), my rationale being, "I want to make sure I would be working with
competent peers." And I don't give a fuck if it rubs them the wrong way.

~~~
NegativeK
If your rationale is to find out if you're going to work with competent peers,
why not asK a question that leads into a proper, deeper technical discussion?

~~~
nathanb
He meant his stated rationale. I'm sure his actual rationale is to try and
help the interviewer achieve enlightenment by turning his own pointless
methods back on him.

------
sergiotapia
I became unreasonably angry while reading this. I guess it struck a nerve with
me for some reason.

During my interviews, I was very charismatic, confident in my skills, was
asked technical question that were things I would need day in day out. I
landed the job on 100% of those interviews.

There was this one time were the guy kept asking me crap I would never EVER
need while working for his company.

Binary tree's, linked lists, pointer arithmatic. "What the fuck?", I thought
to myself. This was for a C# developer position for a small 20 person company.
Anyways, I thanked him for his time and left. He called me with an offer two
weeks later, and I declined. Not going to waste my time with that crap.

\---

99% of us will never work for Google, or Amazon, or Twitter - but for your run
of the mill software shops. And that's ok.

~~~
mieubrisse
Out of curiosity, why do you consider binary trees, linked lists, and pointer
arithmetic to be so out of the bounds of possibility for work at a job? Those
strike me as skills I might find invaluable in one of my software engineers
depending on the job.

~~~
jff
You probably won't be doing pointer arithmetic in C#. It's been about 5 years
since I wrote any C#, but I don't _remember_ any... mostly I remember it as a
Java clone, which would preclude pointer arithmetic.

~~~
charliesome
C# has pointers (although you're rarely going to use them)

~~~
jff
You're right on the rarely using them part, I don't think I used a single one.
Thanks for the clarification!

~~~
charliesome
The only time I've ever used them is to speed up drawing. Bitmap.SetPixel is
super slow compared to taking a pointer to the raw image data and writing
there directly.

------
lessnonymous
As a hiring manager, the thing I find most interesting on posts like this
(ignoring that the analogy is TERRIBLE) are the comments of people used to
being on the other side of the desk. I don't think we (as interviewers) do a
good job of explaining why we ask the questions we ask. And I don't think we
do a good job of communicating what our job is.

Our job is to stop you getting hired.

If we get 100 people applying for the job, then our job is to not employ at
least 99. So we are looking for anything that identifies you as being one of
the 99.

That you could go away and learn what color the middle wire is is great. But
the guy next to you has been fixing wiring in distributor caps for years. And
right now, I need people that know what color the middle wire is.

~~~
mmorett
"That you could go away and learn what color the middle wire is is great. But
the guy next to you has been fixing wiring in distributor caps for years. And
right now, I need people that know what color the middle wire is."

If you're hiring a mechanic, yes. However, the analogy was pointing out that
the person being asked the question was a potential car renter. _That_
specific knowledge is not relevant as a car renter.

~~~
lessnonymous
Yes, the analogy is silly.

~~~
hatcravat
Actually, I think you misunderstand the analogy. The color of the middle wire
on the distributor is something you'd like a prospective mechanic to know, so
he isn't learning on your time. It isn't, however, something that is in any
way relevant to driving a car. I think this is why your comment provoked such
hostile responses.

The _programmer_ equivalent of the middle wire color question is something
like, "Is the 3-phase power supply on XYZ mainframe wired in a delta or wye
configuration? As a followup, what is the input frequency tolerance?" A
sysadmin might need to know that, and an electrician certainly would, but it
is far, far outside the purview of a programmer. [Edit: I'm assuming the
programmer to be someone writing software running on the mainframe, not the
firmware for a microcontroller in the power supply]

Maybe you're just a very good interviewer and haven't had to deal with the 90%
that are crap? :+)

------
aidenn0
This makes no sense.

Just like having a drivers license is no guarantee you are a good driver,
having many years of job experience programming is no guarantee you are a
programmer.

On the other hand, you are liable for any damage you do to a car you rent,
plus the company is fully insured in the case you do any damage and can't pay.
Hiring and firing someone (which is the only real way to know if someone is a
good developer) is very expensive.

Here's what it would be like if we hired programmers like we rent cars:

You walk in to a software company and are immediately hired under these
conditions: "We'll take you on for 6 months, but if it doesn't work out you
need to pay us back all of your salary, plus benefits and payroll tax"

~~~
digitalmerc
Actually it does, and spot on to boot.

He's not saying "don't find a good programmer." He's saying that the questions
they ask get them no closer to finding out whether he is a good programmer.

~~~
abstractbill
_He's saying that the questions they ask get them no closer to finding out
whether he is a good programmer._

A lot of the time they're not meant to. They're meant to figure out whether
he's a _bad_ programmer (or bad cultural fit, or something else bad).

The cost of hiring someone bad is _way_ higher than most people would guess.
I've come to believe that in many cases the questions asked in an interview
almost don't matter - they're just there to give you an opportunity to fail,
or to say something incredibly dumb or ignorant or obnoxious so that the
interviewer can quickly reject you and avoid an expensive mistake.

~~~
slurgfest
If you hire someone who is boring and has no obvious problem but isn't very
productive, you have your ass covered. His lack of productivity is his fault.
If you hire someone exceptionally useful with some notable problem, or even
just some notable flavor someone doesn't like, it is something you should have
noticed and you are liable. A lot of companies want an unblemished calf more
than they want a Zed Shaw.

------
tobyjsullivan
I've given enough interviews to know it's all relative.

To cherry pick one example: "What color has the middle wire feeding into the
distributer cap?" implies interviewers ask ridiculously specific questions
that you could "look up if and when you needed to know."

The problem is for some applicants that question could be "how would you
implement Google's PageRank" and for other applicants it can be something as
simple as "what's the difference between an interface and an abstract class."
Think what you want but if you don't think you need to be able to answer the
latter, it's probably not going to work out between us.

To be honest, of the few interviews where I've been the applicant, the
questions have always been fair and I've never been treated with the level of
disrespect that was demonstrated in this scenario. That said, I'm completely
willing to believe I've just been lucky so far.

~~~
bicknergseng
The problem I perceive is that that question gets asked to people who will
never need to know it. I too often see people interviewing for front end web
or javascript positions asked questions about binary search trees or something
that totally doesn't relate to front end development, instead of asking about
closures or what they think about coffeescript. Honestly, I think at this
point if you're asking about various search algorithm big o timings to find
out if a programmer can build an iOS app or do Rails dev, you're doing it
wrong.

------
w33ble
The poor interview process is one thing, but what irks me most is that almost
nobody offers you a chance to meet the team, even when they make you an offer.
That's been my general experience so far anyway. It sucks, because your only
exposure to anyone was the hiring manager, and maybe a lead, and all they did
was ask questions about what you memorized about whatever language(s).

~~~
mmorett
My pet peeve is that you are interviewed as though you should be God, and you
would be so _lucky_ and _privileged_ to work on this pristine, perfect
codebase...only to find out that the codebase is not all that perfect, and the
development processes are not scrum or agile or XP, but instead "run around
like chicken with your head cut off, just get it done!"

Perhaps this is the queue for someone to suggest "that's why we try so hard to
prevent bad people from getting hired". :-)

~~~
w33ble
> you would be so lucky and privileged

I hate those interviews and interviewees that have that attitude too.
Especially since the opposite is actually the case. It's so incredibly easy to
find work as a developer right now, you need to tell me why I should come work
for you. Remind me why I'm sitting here talking to you instead of somewhere
else that could be more exciting.

------
tokenadult
It's very easy to decry company hiring procedures. That happens all the time
here on HN, and for a very good reason--most company hiring procedures are not
based on research and are demonstrably suboptimal for hiring the best people.
We discuss this a lot on Hacker News because many of us have been looking for
jobs or looking for people to hire some time in our adult lives. From
participants in earlier discussions I have learned about many useful
references on the subject, which I have gathered here in a FAQ file. The
review article by Frank L. Schmidt and John E. Hunter, "The Validity and
Utility of Selection Models in Personnel Psychology: Practical and Theoretical
Implications of 85 Years of Research Findings," Psychological Bulletin, Vol.
124, No. 2, 262-274

[http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...](http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf)

sums up, current to 1998, a meta-analysis of much of the HUGE peer-reviewed
professional literature on the industrial and organizational psychology
devoted to business hiring procedures. There are many kinds of hiring
criteria, such as in-person interviews, telephone interviews, resume reviews
for job experience, checks for academic credentials, personality tests, and so
on. There is much published study research on how job applicants perform after
they are hired in a wide variety of occupations.

[http://www.siop.org/workplace/employment%20testing/testtypes...](http://www.siop.org/workplace/employment%20testing/testtypes.aspx)

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.

The overall summary of the industrial psychology research in reliable
secondary sources is that two kinds of job screening procedures work
reasonably well. One is a general mental ability (GMA) test (an IQ-like test,
such as the Wonderlic personnel screening test). Another is a work-sample
test, where the applicant does an actual task or group of tasks like what the
applicant will do on the job if hired. (But the calculated validity of each of
the two best kinds of procedures, standing alone, is only 0.54 for work sample
tests and 0.51 for general mental ability tests.) Each of these kinds of tests
has about the same validity in screening applicants for jobs, with the general
mental ability test better predicting success for applicants who will be
trained into a new job. Neither is perfect (both miss some good performers on
the job, and select some bad performers on the job), but both are better than
any other single-factor hiring procedure that has been tested in rigorous
research, across a wide variety of occupations. So if you are hiring for your
company, it's a good idea to think about how to build a work-sample test into
all of your hiring processes.

Because of a Supreme Court decision in the United States (the decision does
not apply in other countries, which have different statutes about employment),
it is legally risky to give job applicants general mental ability tests such
as a straight-up IQ test (as was commonplace in my parents' generation) as a
routine part of hiring procedures. The Griggs v. Duke Power, 401 U.S. 424
(1971) case

[http://scholar.google.com/scholar_case?case=8655598674229196...](http://scholar.google.com/scholar_case?case=8655598674229196978&q=Griggs+Duke+Power&hl=en&as_sdt=2,24)

interpreted a federal statute about employment discrimination and held that a
general intelligence test used in hiring that could have a "disparate impact"
on applicants of some protected classes must "bear a demonstrable relationship
to successful performance of the jobs for which it was used." In other words,
a company that wants to use a test like the Wonderlic, or like the SAT, or
like the current WAIS or Stanford-Binet IQ tests, in a hiring procedure had
best conduct a specific validation study of the test related to performance on
the job in question. Some companies do the validation study, and use IQ-like
tests in hiring. Other companies use IQ-like tests in hiring and hope that no
one sues (which is not what I would advise any company). Note that a brain-
teaser-type test used in a hiring procedure could be challenged as illegal if
it can be shown to have disparate impact on some job applicants. A company
defending a brain-teaser test for hiring would have to defend it by showing it
is supported by a validation study demonstrating that the test is related to
successful performance on the job. Such validation studies can be quite
expensive. (Companies outside the United States are regulated by different
laws. One other big difference between the United States and other countries
is the relative ease with which workers may be fired in the United States,
allowing companies to correct hiring mistakes by terminating the employment of
the workers they hired mistakenly. The more legal protections a worker has
from being fired, the more reluctant companies will be about hiring in the
first place.)

The social background to the legal environment in the United States is
explained in many books about hiring procedures

[http://books.google.com/books?hl=en&lr=&id=SRv-
GZkw6...](http://books.google.com/books?hl=en&lr=&id=SRv-
GZkw6TEC&oi=fnd&pg=PA271&dq=Validity+and+Utility+of+Selection+Models+in+Personnel+Psychology&ots=iCXkgXrlOV&sig=ctblj9SW2Dth7TceaFSNIdVMoEw#v=onepage&q=Validity%20and%20Utility%20of%20Selection%20Models%20in%20Personnel%20Psychology&f=false)

[http://books.google.com/books?hl=en&lr=&id=SRv-
GZkw6...](http://books.google.com/books?hl=en&lr=&id=SRv-
GZkw6TEC&oi=fnd&pg=PA95&dq=Validity+and+Utility+of+Selection+Models+in+Personnel+Psychology&ots=iCXkgXrnMW&sig=LKLi-
deKtnP20VYZo9x0jfvqzLI#v=onepage&q=Validity%20and%20Utility%20of%20Selection%20Models%20in%20Personnel%20Psychology&f=false)

Some of the social background appears to be changing in the most recent few
decades, with the prospect for further changes.

<http://intl-pss.sagepub.com/content/17/10/913.full>

[http://www.economics.harvard.edu/faculty/fryer/files/Fryer_R...](http://www.economics.harvard.edu/faculty/fryer/files/Fryer_Racial_Inequality.pdf)

[http://books.google.com/books?hl=en&lr=&id=frfUB3GWl...](http://books.google.com/books?hl=en&lr=&id=frfUB3GWlMYC&oi=fnd&pg=PA9&dq=Validity+and+Utility+of+Selection+Models+in+Personnel+Psychology+%22predictive+validity%22+Duke+Power&ots=5O9Hx_E1vY&sig=g-zERWztBWq3h4guEuv9VVkTh8I#v=onepage&q=Validity%20and%20Utility%20of%20Selection%20Models%20in%20Personnel%20Psychology%20%22predictive%20validity%22%20Duke%20Power&f=false)

Previous discussion on HN pointed out that the Schmidt & Hunter (1998) article
showed that multi-factor procedures work better than single-factor procedures,
a summary of that article we can find in the current professional literature,
for example "Reasons for being selective when choosing personnel selection
procedures" (2010) by Cornelius J. König, Ute-Christine Klehe, Matthias
Berchtold, and Martin Kleinmann:

"Choosing personnel selection procedures could be so simple: Grab your copy of
Schmidt and Hunter (1998) and read their Table 1 (again). This should remind
you to use a general mental ability (GMA) test in combination with an
integrity test, a structured interview, a work sample test, and/or a
conscientiousness measure."

[http://geb.uni-
giessen.de/geb/volltexte/2012/8532/pdf/prepri...](http://geb.uni-
giessen.de/geb/volltexte/2012/8532/pdf/preprint_j.1468_2389.2010.00485.x.pdf)

But the 2010 article notes, looking at actual practice of companies around the
world, "However, this idea does not seem to capture what is actually happening
in organizations, as practitioners worldwide often use procedures with low
predictive validity and regularly ignore procedures that are more valid (e.g.,
Di Milia, 2004; Lievens & De Paepe, 2004; Ryan, McFarland, Baron, & Page,
1999; Scholarios & Lockyer, 1999; Schuler, Hell, Trapmann, Schaar, & Boramir,
2007; Taylor, Keelty, & McDonnell, 2002). For example, the highly valid work
sample tests are hardly used in the US, and the potentially rather useless
procedure of graphology (Dean, 1992; Neter & Ben-Shakhar, 1989) is applied
somewhere between occasionally and often in France (Ryan et al., 1999). In
Germany, the use of GMA tests is reported to be low and to be decreasing
(i.e., only 30% of the companies surveyed by Schuler et al., 2007, now use
them)."

Integrity tests have limited validity standing alone, but appear to have
significant incremental validity when added to a general mental ability test
or work-sample test.

<http://en.wikipedia.org/wiki/Employment_integrity_testing>

[http://apps.opm.gov/ADT/Content.aspx?page=3-06&JScript=1](http://apps.opm.gov/ADT/Content.aspx?page=3-06&JScript=1)

<http://www.princeton.edu/~ota/disk2/1990/9042/9042.PDF>

[http://www.hotelschool.cornell.edu/research/chr/pubs/reports...](http://www.hotelschool.cornell.edu/research/chr/pubs/reports/abstract-14602.html)

~~~
codemac
You post this every time, and I want to decry the astro turfing..

but it's good information, well referenced, and I don't have the background or
time to refute anything you've said.

~~~
greendestiny
I don't think posting the same information again and again is welcome. The
people who might be inspired to debate it simply can't have a discussion about
it every time it appears - and it goes beyond wanting to engage with the
community and share something and becomes an attempt to manipulate. I'd
certainly encourage tokenadult to stop posting it.

~~~
dllthomas
I think the optimal solution might be to post a link to the comment on a
previous version of the article, where the discussion's been had before?

~~~
technotony
I haven't seen this comment before and took something useful from it, so it
seems ok to repost it. Your suggestion to link to the previous posting and
it's discussion seems like the best approach.

------
jedmeyers
Better analogy would be shipping company hiring a truck driver and asking him
those questions. And also requiring experience piloting Formula One cars for
at least three years, knowledge of how to operate large construction equipment
and ability to replace the tire on a truck with bare hands.

------
motters
Evidently other people must have been through the same types of interviews as
I have.

------
beefman
Maybe applicants need insurance. If they don't work out, their insurance
company refunds the employer their salary and the opportunity cost of their
bad commits. This way, applicants get muscled out of the job market gradually
by high insurance rates, rather than with a brick wall filter.

~~~
ChristianMarks
That's not a bad idea at all. But it's unlikely to be very useful for
specialized work, unless the insurance is highly specialized, and in that case
it is likely to be as expensive as malpractice insurance.

------
npsimons
While this seems "spot on" at first glance, I can tell you that when I
interviewed at Google and Amazon (two years ago), it wasn't anywhere near this
bad. Both places asked what might seem like contrived technical questions, but
the thing is, you have to pick something that can be tested in an hour (or
less). That, and it's not the answer that matters, but more your process of
working a problem. They didn't seem to care too much about experience with
specific tools. I guess it depends on the organization, and I can see how many
places would be much worse. My question is, if they care so much about
experience with specific tools, why do they even get to an in-person interview
with someone who doesn't have it on their resume?

~~~
TheCapn
My experience with Amazon was similar but at the end I was led to ask: "if the
1hr filter process isn't efficient at finding the best candidates, why do they
do it?"

I think in the end its a balance of basic filtering vs. HR requirements. The
process has to be objective and quantifiable so they're covered in the event
of anyone calling foul play. Everyone gets the same treatment and there is a
paper trail of reasons for why they turned you down.

~~~
slurgfest
The process only has to look objective and quantifiable. Everyone doesn't get
the same treatment, but it's not actionable if the differences are all
deniable and have rationalizations like 'culture fit'. People can and do still
hire who they want for whatever reason, they just claim some objective reason
for it.

~~~
TheCapn
Ah yes, I completely agree. I really should have clarified by the HR part in
that it is meant for HR's use and not the actual hiring manager/interviewer.
If they want to sabotage the interview or otherwise they still can; its just
harder to prove-if at all

------
markhelo
I agree with parts of it, but I disagree with the basic premise that hiring
programmers is like renting cars. When you hire a programmer, it is like
hiring a car mechanic, not a car driver. Some of the questions do seem
appropriate to ask to a car mechanic.

~~~
moccajoghurt
If you see a programming language as a tool like photoshop you certainly can
see the renting car point.

I don't think every Java Coder would be able to tell how the internal
mechanics of Java work. They aren't Java mechanics, they're just driving Java.

~~~
markhelo
Car Mechanics dont build the car parts or research into how to build the most
efficient engine, but do need to know how to apply the knowledge of those
parts. The best car mechanics can apply the science but may not be the best
car researchers. Thats why in my opinion, some questions do make sense for a
car mechanic.

If you were using the photoshop analogy, then I think to interview someone,
you need to ask them how different features of Photoshop work, not how
Photoshop was built but also not how they draw in general, IMO. You may be a
great artist, but if you can't understand Photoshop features and what they
mean you will fail to create a great digital painting.

~~~
JoshuaRedmond
The car mechanic analogy is an interesting one that I came across while
touring universities to find one that I liked. A parent at one of the Q&A
sessions asked what the difference was between Computing and IT (in a UK
education context). The degree director replied that an IT course is like
learning to drive a car, whereas Computing is like learning to be a mechanic.
(Context: IT classes pre-university used to consist of learning to use Word,
Excel and Powerpoint.) So I suppose whether the analogy works depends whether
you want your programmer to find and plug a hole in your exhaust pipe, or to
work out how to make a more efficient catalytic converter.

------
ChuckMcM
Ah yes, another person describing their Google interview experience. They do
leave a lot of solid candidates out but in their defense, when I was there,
being able to survive the non-intuitive interview process was a good indicator
you could survive the non-intuitive business dynamics.

If didn't really crush people when they didn't get called back it would make
it funny. Sort of like the Monty Python sketch
<http://www.youtube.com/watch?v=zP0sqRMzkwo>

------
davidw
"E se me nona gavesse e rode sarìa na carioea", as they say here in the
Veneto, which, literally translated, means "if my grandmother had wheels,
she'd be be a wheelbarrow".

~~~
geon
And what does it mean?

~~~
davidw
The literal translation is pretty clear, actually. If [something
ridiculous/impossible] then [something else ridiculous/impossible]. In other
words the comparison is a bit of a stretch.

------
quarterto
I have had this interview. I didn't get the job.

~~~
funkaster
I'm actually interested to know what kind of developer gets the job. And also,
what was he/she thinking when accepting the job, was it out of necessity?
because he/she liked the interview process? (I'm asking seriously)

------
oboizt
hehe, yeah, I've been through this several times.

I think it's funny when the recruiters try and lie at the beginning by saying
a later interviewer may or may not be out sick and there is the possibility
for some interviews to be cancelled and the day cut short. We all know they
want to send you home if you screw up in the beginning. It's not a secret.

------
loeg
Now, maybe I've gotten lucky, and I've only interviewed at a few companies
(well-known ones include: Google, Amazon, Facebook), but I've never had an
experience as bad as that painted by this analogy.

In general, the interview questions I've gotten are designed to test general
CS knowledge and the ability to translate an algorithm into code. This is
important, and as an interviewer myself, a lot of candidates fail at the
translating to code step.

Design questions are (at a high level) maybe even closer to "how would you do
your job?" than coding questions.

I have yet to see a company ask for specific experience with VB.net 2012
edition and exclude candidates like myself who are only familiar with
C/Python/Java. If they do, I'd recommend straight out lying (for languages).
You can pick languages up really quickly. For platforms, maybe you really
should know it and it is actually relevant to your potential job.

~~~
elbear
If a company asks for specific experience with a technology and exclude
candidates familiar with other technologies, I recommend getting out of there.

~~~
loeg
If the job you are applying for is to work on a rails site or develop a mobile
app, I would argue that it is pretty important that you are already familiar
with those technologies (and their pitfalls)…

I wouldn't exclude someone unfamiliar with a specific framework, but as an
employer you understand that ramping them up to speed is going to take a
significant amount of time.

~~~
elbear
Right and my point still stands. If you don't have the expertise that they
require specifically, don't waste your time, or worse, lie.

------
bobwaycott
The problem with this article (and nearly every attempt at analogous
argumentation by anybody, ever) is that the writer cannot construct a
homologous argument, which ultimately relegates the entire attempt to, at
best, being mildly entertaining, but otherwise unhelpful. I've attempted many
times to draw analogies in argument, but when your audience by and large
shares the experience, they're useless. When attempting to dispute a point, or
bring notice to something that you'd like to see changed, it's better to stick
with homologous arguments and eschew analogies. Otherwise, you're just going
to get mired down in quibbling over how the analogy doesn't hold, and
completely sidetrack any attempts to discuss what you're really wanting to
discuss.

------
fecak
What I think candidates tend to miss is some of the potential ulterior motives
that employers have when asking esoteric questions or certain task requests.
The list of what candidates label as 'inappropriate' for interviews has become
longer, or perhaps candidates have simply become more vocal about it. I wrote
another article in response to this, in order to outline why certain lines of
questioning (esoteric, riddle, impossible, inane) may be used to try and learn
something deeper about the candidate. Candidates need to understand that it
isn't always just about your ability to answer a question.
<http://news.ycombinator.com/item?id=5073791>

------
suhailpatel
This is absolutely spot on.

------
com2kid
The only times I have been asked language specific questions are when I was
selling myself as a language expert to fix some particular problem in some
particular language.

I will however say that 90% of the interview questions I have been asked are
heavily biased towards C type answers, although I did manage to use Scheme
once!

Sure a linked list problems don't technically have to be written with
pointers, but we all know what the interviewer is asking for.

Actually that brings up a good idea, I am going to come up with a bunch of
contrived answers to the "find a loop in a linked list" problem, memorize them
all, and next time someone asks me that question I'm going to give 5 weird
answers in the course of 30 minutes.

------
Tloewald
I've been through a lot of hiring processes, on both sides of the desk, and I
don't know what the article is trying to satirize. The worst, most bizarre
hiring process I've ever been involved with bore no resemblance to anything in
this little drama, and the analogy is bad. (My immediate reaction to the title
was that car rental is based on what's available and how spiffy the car is
(fairly rational) whereas programmer hiring is abased on jumping through hoops
(e.g. Dumb C trick questions or programming challenges or certifications),
who's available, and some weird perception of value almost guaranteed to be
out of whack with reality.

------
hosh
It's funny in an absurd way. It is absurd because software technology grow
significantly faster than car technology. Asking someone to write something
with 1998 technology versus 2012 technology is different than asking someone
to drive a 1998 model car and a 2012 model car.

It's true, if you have a solid foundation software, you _can_ catch up to the
2012 platform. It will take some time.

So I think it is less that software changed so fast that solid programmers are
unable to catch up so much that software changed so fast that recruiters have
been unable to keep up.

------
rsheridan6
I just had to interview people for a (non-tech) job who didn't even want it,
and who we had no intention of hiring, because of our company's rules about
how many people you have to interview before hiring. At least the hiring
process described in the post has some sort of point, however badly executed.

------
acchow
What's with this "only Subaru" analogy? What I've found is more along these
lines:

"Are you sure I'm qualified? I don't feel like I'd be very useful. I've never
done Java, only C++ and JS and lisp" "No, you'll be perfect. We don't hire
people for specific languages"

~~~
falcolas
I think you're lucky.

Of course, my experience is with Python, and trying to get hired by a Ruby
shop (no matter my experience outside of work with Ruby or any other language,
or my experience with the rest of the stack) is impossible.

Perhaps it's a different world the lower down the language abstraction level
you look.

~~~
dllthomas
I've found a mixed bag, for sure, with extensive C and C++ experience. Of
course, recruiters love sending things that don't even make sense - bringing
me in as a permanent employee in a language I don't know well is probably
fine; I'm smart, I learn well, I won't have bad habits. Bringing me in on a 3
month contract on a language I haven't touched, not so much...

Regarding your Ruby-outside-work experience, is it on publicly visible
projects?

------
amaxerlite
Question since I'm in the middle of interview sright now (I haven't
experienced anything like this other than the last part of negotiations): how
and what do you look for in terms of team and company for? for some reason in
not sure myself.

------
tambourine_man
Car analogies are usually bad. This one is worse.

The underling problem is very true though.

------
snambi
The author is confused.

1) While renting a car you are paying. 2) Interviews are for getting PAID.

It is buying versus selling.

The buyer will be cautious, try to get the best deal. The seller will be
sweet, nice and somehow sell it.

So, we should ignore this post.

------
deepinsand
A similar analogy but from a different angle: <http://blog.212labs.com/?p=53>

I argue recruiters should act MORE like car salesmen =)

------
clyfe
Related [http://blog.jitbit.com/2011/05/what-if-drivers-were-hired-
li...](http://blog.jitbit.com/2011/05/what-if-drivers-were-hired-like.html)

------
bobwaycott
Hiring feels broken in many businesses, typically because it is executed by
people who do not understand the target position, especially with technology.
And, like the author tried to focus on, it doesn't help when the focus is far
too heavily on a specific piece of the tech puzzle, and not on the overall
talent and aptitude of the candidate her/himself.

I've both participated in and executed hiring processes in a mid-size (~500
emps) corporation where just about everyone wears ties or biz-casual (gross).

I sat in on one department's hiring rounds with about six candidates. What the
dept was _looking for_ was a programmer who had MS/.NET experience to develop
on the MediaRoom platform (I managed the internal development team, hence my
sitting in; responsibility for operating MediaRoom was under the other dept,
however, so this candidate was not going to be able to be part of my team
(stupid corporate organizational bullshit where dept mgrs squabble and
scramble for stupid feelings of control and shit)). The questions the dept
came up with and spent 1-2 hrs torturing the candidates with included _zero_
questions about programming experience and aptitude-gauging type of inquiries.
No questions about past projects, current interests, or anything remotely
helpful. All the questions that were technical revolved around sysadmin tasks
or how many damn acronyms the candidate was familiar with from MS's alphabet
soup of platforms & products--literally asking if the candidate knew what they
meant, not if they understood purpose or anything else like that. For a
fucking programming job. The position stayed open for a _year-and-a-half_
without being filled.

Biggest problem I saw? The interview was designed by a guy with zero
programming experience trying to hire a programmer. Why the questions he
chose? Best I can tell, servers and sysadmin tasks were something his dept had
long done, and something he semi-understood (but didn't do himself).

In contrast, when I ran hiring for my dept, I requested explicit permission to
direct the interviews myself, instead of having them led by HR (though an HR
rep was still there). Before setting up an interview, my team and I would meet
the candidate for lunch just to get to know them a bit. It was sort of our
version of testing- or phone-based screening processes. We could figure out
more in an hour lunch that we could _trust_ than automated tests or other
devices.

After the first candidate's official interview, I heard HR was talking about
it. By the second candidate's interview two days later, the SVP of HR sat in
on the process with the other HR person who was always there. What was most
interesting to HR, apparently, was that candidates didn't display any of the
typical nervous behaviors that are so common. About 10 minutes in, we had them
relaxed, talking and smiling and laughing like normal, discussing things they
did in their free time to take a break from programming, talking about the
projects they'd loved and hated the most--even talking about times they'd
fucked up. That last bit was really fun to watch HR react to, as they hadn't
ever experienced anyone talking about times they'd done something _wrong_ in
an interview.

There were no bullshit how-would-you-resolve-a-stupid-conflict-with-a-coworker
questions. We asked some general tech and programming questions, shot the shit
about open source projects that impressed the candidate. The focus, though,
was on collaborative tasks where the entire dev team went through a couple
exercises with the candidate as if s/he was part of the team already, letting
the candidate lead, but basically serving as a normal team would--asking
questions, raising objections, saying what a good idea or novel approach
something was. It was a great way to get a feel for what it'd be like to work
through a problem together.

By the time we'd interviewed 4 people, we'd already hired 2 of them and I had
to push pretty hard to get a very competitive offer out immediately before
finishing all the rounds. I nagged the hell out of them till they were willing
to break their own rules of waiting till all interviews were done. Our
positions did not stay open even one month before we hired three new people.
But making them successful required a lot of effort on my part to plead and
nag and bargain to get processes bent so we could pull it off.

Hiring feels broken in many businesses. But it doesn't have to be.

 _Disclaimer:_ This was a mid-size company. I'm not saying that companies who
receive hundreds or thousands of applicants can afford to take the time to do
things this way. I can say that every interview that has ever meant a damn to
me were the ones where the people interviewing actually took the time to be
relaxed, get to know me a bit, and just make interviewing more like having a
conversation. It's not coincidence that each one of those happened to be over
coffee or lunch or somewhere away from a conference room and table as the
first meeting.

------
walshemj
Right so to ace the interview all one needs is some white racing overalls and
a white simpson Daimondback helemt accessorized with a vintage HP calculator
and a set of steam tables.

Some say that his not only the man-in-the-middle, he's at both ends and has
wiretaps on Alice, Bob, Carol and Dave. and that he once crashed a 10 way IBM
sysplex by staring at at it all we know is hes the stigs nerdy cousin.

------
jebblue
This article rocked! Yes!! Todd should write movie scripts. I loved that.

------
aaronsnoswell
Wow. Sure sounds like the author had some bad hiring experiences.

------
atarighat
Terrible analogy...

------
venomsnake
Why no one asks questions that show deep understanding of the work and not
technical details that can be googled in a second.

Like - can you land Curiosity with off the shelf java and JVM? Why or why not?

~~~
chrisbennet
"Land it? Yes. Successfully? Not so much..."

~~~
err
Welcome aboard!

------
lucdurette
I kind of agrees with the above.

------
hkon
Why not type your problems flat out. Trying to "abstract" the problem by
transferring it to a completely different and reverse analogy just makes the
whole post artificial.

I was actually wondering if this was written by a programmer or a man that
hires programmers at first...

