How to hire jugglers

Consider the following fictional interview

“Circus Manager: How long have you been juggling?

Candidate: Oh, about six years.

Manager: Can you handle three balls, four balls, and five balls?

Candidate: Yes, yes, and yes.

Manager: Do you work with flaming objects?

Candidate: Sure.

Manager: …knives, axes, open cigar boxes, floppy hats?

Candidate: I can juggle anything.

Manager: Do you have a line in funny patter that goes with your juggling?

Candidate: It’s hilarious.

Manager: Well that sounds fine. I guess you’re hired.

Candidate: Umm… Don’t you want to see me juggle?

Manager: Gee, I never thought of that.”

“It would be ludicrous to think of hiring a juggler without first seeing him perform. That’s just common sense. Yet when you set out to hire an engineer or a designer or a programmer or a group manager, the rules of common sense are often suspended. You don’t ask to see a design or a program or anything. In fact, the interview is just talk.”

– HIRING A JUGGLER, Chapter 15 of Peopleware: Productive Projects and Teams (Second Edition) by Tom DeMarco and Timothy Lister (quoted by Reg Braithwaite in this post )

It is hard to generalize, but according to these two authors this tendency is pretty common in our industry: picking people based only on reading résumés and holding personal interviews.

Personally, when I have done it that way I have had bad experiences, because a résumé will say anything you want it to.

In particular, for computer engineers, even if they are going to be project managers, my main filter is finding out whether they can program. Some people hire project managers who are not computing people. I don’t buy that, because I believe a good programmer is a mentally disciplined person. Probably the only other professional I would hire as a project manager is someone who studied philosophy. I mean it.

Since I don’t expect to hire the best programmers on the first try, I have to set up some kind of interview method that lets me get good people. It isn’t easy. I have been hiring people for years, and I have had every kind of result.

The first thing I measure is whether the candidate can program. The FizzBuzz filter is astonishing. In an earlier post I proposed this test to you; normally this question or a similar one is part of my entrance exam. In my experience 40% don’t answer it, or answer it wrong. The others are more advanced programming questions, or requirements analysis, and always some question that involves building a model.

Over the years I have noticed that computer engineers come out of universities with less and less programming experience, which is a shame. It’s like soccer players who can’t pass or head the ball, to paraphrase Franco Catrin.

For me it is important that engineers develop communication skills; that is what I have been paying the most attention to lately. I’m no longer interested in hiring the smartest ones; I prefer the least self-absorbed. The other thing I care about is that they not be reckless; I’m tired of suffering through the maintenance of code badly copy-pasted from Google.

More and more I interview and select smart, passionate young people who want to learn to program, but who have had terrible training. It is not our role as a company to train them, but we have had to do it. At the very least, though, we have to put in a low-pass filter like FizzBuzz, because the least you can expect of a computer engineer is that they can write a loop with a couple of ifs. Or am I wrong?