
Two ways to hire (and a wrong way) - nreece
http://sethgodin.typepad.com/seths_blog/2009/08/two-ways-to-hire-and-a-wrong-way.html
======
miloshh
The article could as well be called "three wrong ways to hire".

I don't understand why academia has long known the right way to hire, but the
software industry keeps missing it. The right way is to let the candidates
give a 30-60 minute talk about their previous projects, and then fry them with
questions that came up in the talk.

Imagine a famous university wants to hire a top-quality math professor. How
about asking him tricky high-school math questions for an hour, to see if he
makes a mistake? Or how about cutting it down to 5 minutes, since that's
enough to assess the "chemistry"? Or, what about choosing only from a pool of
contractors that worked with the university before, rather than letting the
best ones to apply? Sound stupid? Well, yes, it is stupid.

~~~
troels
This still has the weakness of asserting the candidates rhetoric skills, as
much as her technical skills. That said, almost any interviewing situation
would.

------
mustpax
Of course, if you have concrete questions to ask the candidate that gauge
their problem solving ability, motivation and attitude 5 minutes is not
enough. If you are only looking for a likable candidate for a technical
position, you are doing it wrong to start with. But then if you're a marketing
type, like Seth Godin, you probably can't tell good and bad developers apart
without working with them. So maybe somebody else should be making these
technical hiring decisions.

~~~
willchang
Once I was interviewing someone with a Ph.D in some vaguely IT-related field.
She seemed kind of flaky but I assumed it was because she was a lot smarter
than I was. I pressed on, and an hour later discovered that she didn't know
what a typical size for a C pointer was. She was actually quite indignant when
this occurred, saying in so many words that this was beneath her. Anyway I'm
glad she was not hired, and didn't end up managing me. Our team worked on a
project where data structures and storage were paramount concerns.

The moral of the story is, it takes a lot more than 5 minutes to figure out
whether someone is hirable, and often a lot less than a month.

~~~
mighty
> She seemed kind of flaky but I assumed it was because she was a lot smarter
> than I was. I pressed on, and an hour later I discovered that she didn't
> know what a typical size for a C pointer was.

That doesn't mean she's actually flaky or not smart. There's tons of info that
smart programmers won't know off the top of their heads, either because they
haven't worked in a given domain before, or haven't worked in it for a while.

She may well not have been qualified depending on what level of domain
familiarity was expected from the get-go, but this implies nothing about her
intelligence or capacity for domain competence.

~~~
willchang
Your making the claim that the above implies _nothing_ about her capacity for
domain competence is a bit much. I thought it was a near-perfect diagnostic of
her incompetence, and I'd be curious if anyone can sketch the profile of a
very competent programmer, alive today, that doesn't have an inkling of the
above fact. I don't think you can.

~~~
mighty
The problem is that you're conflating incompetence with a lack of capacity for
competence. In other words, the mere fact of not knowing something implies
that one can never know it. If that were true, nobody would know anything.

What I'm saying is, you may well be correct in your assessment that she was
incompetent for the job, but that assessment doesn't qualify you to make the
further implication that's she's not smart, or inherently incapable of
competence.

I've noticed you added the bit about her being indignant and suggesting that
such knowledge was beneath her. That does suggest she would be resistant to
acquiring domain competence, which certainly doesn't bode well even if your
company was open to letting the hiree acquire it on the job. On the other
hand, I can understand her getting pissed off about someone using such a
question as a litmus test.

------
benatkin
I think Joel and Google are right on this one. Letting a bad one through is
much worse than missing a good one. Having half a dozen interviews, rather
than three, may seem tedious, but is probably worth it. Also, companies
already do five-minute interviews. It's called a phone screen.

------
tptacek
Or you can do 4 one-hour interviews, but have each interviewer assess
something different; personality fit, ability to code, domain knowledge,
and... well, maybe you only need 3 interviews, if those are the three axes.

4 people asking the same kinds of questions is silly. But it's hard to
override the "this candidate can't write bubble sort" veto.

------
kwantam
We don't even hire our marketing people this way. They still get technical
interviews, just toned down a bit. LRC circuits are all but a given for the
marketing interviews I do. I don't want to work with someone who has
absolutely no idea how the things he's selling works.

As for technical positions, well, we all know this is absolute bullshit. In
particular, regarding Seth's question whether a junior guy can veto an
interviewee: yes! If the senior guys happen to ask things that the candidate
does well on, but the junior guy exposes a serious hole, we don't hire. In
fact, our argument is precisely the inverse of the one Seth makes here: if we
didn't think it was important to listen to everone's opinion, they wouldn't be
on the interview schedule.

In my mind, nothing is likely to replace 6-8 hours of difficult technical
interviews, not because this is a perfect strategy, but because there
seemingly isn't a better one. I'd love to be proved wrong, though.

