Two ways to hire (and a wrong way) | Hacker News Reader

Two ways to hire (and a wrong way)

sethgodin.typepad.com

12 pointsnreece15 comments

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.

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

I would love to see more of those sorts of interviews. I'd probably ask them to give a 30-60 minute presentation on any advanced topic that interests them and that he thought would be relevant for the company.

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.

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.

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

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.

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.

People who program their entire lifes in high level languages may not need any of this stuff. For example

  * SQL
  * Lisp
  * Haskell
  * Python
  * (I ran out, but please feel free to continue)

> she didn't know what a typical size for a C pointer was.

I'll bite - what is the typical size?

Many of my friends in the embedded world think that pointers are two bytes. My friends in the workstation world used to think that pointers were 4 bytes but many are moving to 8 bytes.

I'd imagine that there are other sizes that are typical in some context. (Physical addresses are rarely 8 bytes but are often more than 4. C programmers who spend all their time in a physically addressed environment might well have an "odd" typical pointer size.)

Exactly. This is one of the posts where the blog commenters would be all over him, if he had comments enabled. He throws decades of industry expertise out the window. The dead give-away is that he tries to pass off a five-minute interview as a new idea, when there's a common and less-expensive practice called The Phone Screen.

Ah, but remember he's making hiring decisions based on "pheromone[s] and body language", which don't come through on phone lines.

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.

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.

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.

Reply on news.ycombinator.com