Back at the beginning of the month I had the pleasure of attending Phil Windley’s CTO Breakfast. The discussion turned to hiring technically competent employees, which was particularly relevant to me, as I’m looking to hire a handful of competent PHP programmers.

The discussion was timely, as I had spent several hours the previous evening reading articles on interviewing strategy, starting with Joel Spolsky, and following links to a slew of sites including techinterview.org, and Malcolm Gladwell’s site (author of Blink and The Tipping Point). The one point from my browsing that stays with me several weeks later is the thought from Gladwell, quoting Frank Bernieri, a psychologist at the University of Toledo:

“[Tricia Prickett, an undergraduate researcher,] took fifteen seconds of videotape showing the applicant as he or she knocks on the door, comes in, shakes the hand of the interviewer, sits down, and the interviewer welcomes the person,” Bernieri explained. … Prickett got a series of strangers to rate the applicants based on the handshake clip, using the same criteria that the interviewers had used. … “On nine out of the eleven traits the applicants were being judged on, the observers significantly predicted the outcome of the interview.”

Malcolm Gladwell, “The New-Boy Network “
Referenced Tue, 13 Dec 2005 23:47 (MDT)

Gladwell emphasizes the point from his own experience. He was meeting with a Harvard student, and asked several questions. He relates the following regarding one of the answers:

Because I had decided, right off, that I liked him, what I heard in his answer was toughness and confidence. Had I decided early on that I didn’t like [him], I would have heard in that reply arrogance and bluster. The first impression becomes a self-fulfilling prophecy: we hear what we expect to hear.

Malcolm Gladwell, “The New-Boy Network “
Referenced Tue, 13 Dec 2005 23:47 (MDT)

I’ve seen this as I’ve sat on both sides of the interview table. While working at a private university, I was asked to hire and train 21 employees in just over a month. It was just prior to the start of the semester, so we had numerous candidates to choose from. I can still recall several candidates who made an impression one way or the other within the first few minutes—and their technical responses made little difference in the final outcome.

Asking Technical Questions

While at the CTO Breakfast, another participant expressed some frustration in finding developers locally. He was asking technical questions to his interviewees, and was disappointed none had thus far answered at a level he preferred. Others present suggested the question might be too specific, and that more general questions might be more worthwhile. If we ignore for the moment the suggestion that interviews may be decided in the first twenty seconds, what questions are appropriate?

When applying for a data reporting position at a major internet retailer, the interviewer tapped the director of software development to ask me technical questions to verify my knowledge of SQL, which were mostly related the effect of null values on data sets. I didn’t feel like I did terribly well, despite several years experience in the field, but he gave me high marks. (We’ve both since left the company, but are still friends, which takes me back to the the thought that the first impression may prove stronger than the quality of answers.)

What kinds of questions prove valuable? Those present at the breakfast suggested several:

• What blogs do you follow, or what web sites do you read regularly?
• What did you Google before this interview?
• Have you contributed to an open source project?
• What programming projects have you completed primarily for personal use (e.g. just for the challenge or fun of it)?

After being hired by the internet retailer, I got to talking with the development manager about the questions he asks developers. He likes to ask candidates to perform some simple string manipulation without using any of the standard C libraries; it serves as a stepping stone to software architecture questions, asking candidates to justify their solution from different perspectives, such as process speed or memory conservation. When interviewing at other companies I’ve been asked about the benefits and hazards of multiple inheritance in object-oriented languages, or what kind of quality controls are appropriate for evaluating data sets. Only once have I been asked a puzzle question (”How many barbers are there in the U.S.?”), which I found to be not only completely out of left field, but also rather useless as an evaluation of my problem-solving ability.

A Realistic Environment

Another question from the CTO Breakfast was whether we (unintentionally) make the interview environment limiting or artificial. If we ask programming questions, do we provide access to Google, or online manuals? I spend much of my time programming in PHP—and I wouldn’t be nearly as effective without the ability to regularly reference the online documentation to verify function names, return values, and attribute order.

The very nature of most interviews (chairs on opposing sides or a desk) also lend to a somewhat restrictive setting. I’m more comfortable when I can pace in front of a whiteboard with a marker in my hand, erasing my first several ideas as a solid solution is built piece by piece. An interview is rarely as forgiving as a whiteboard.

I haven’t had a chance to put into practice the ideas I gleaned from the discussion. (The most recent applicant never showed.) I’m sure I’ll get the chance soon—I still need to hire several web programmers!

Posted in Management