Entries in programming (1)

Saturday
Oct112014

Whiteboard Teamwork?

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.

(From Peopleware by Timothy Lester and Tom DeMarco, 1987.)

Hiring programmers without seeing them program was last year’s technical interview mistake.

But hiring collaborators without seeing them collaborate is today’s.

I was at BarCamp Boston today, and attending a panel on conducting technical interviews got me thinking about the subject of “culture fit”. It’s a ubiquitous phrase in material about technical interviews, but it’s a phrase viewed with skepticism, even derision, by people who view tech company culture with a critical eye. And for good reason! First impressions are ambiguous, it’s easy for unconscious bias to sneak in, and people are inclined to view those more similar to themselves as being more likeable.  But diversity of opinion can be a powerful defense against certain sorts of groupthink-y bad-decision-making patterns, and it can be very worthwhile to have teammate members who disrupt the status quo in productive ways.

“Culture fit” can’t just be ignored, though, since that vague concept does cover some genuinely relevant skills.  It’s important that a new hire will work effectively with other members of their team. But the way those skills are measured in programmer interviews is rather similar to the old way of hiring programmers that inspired the Peopleware parable I quote above: Asking some tangentially-related questions and getting a gut sense that someone will do well.

I’ve never seen tech company interviews that try to test collaboration directly, but I actually have seen one interview process that did. My alma mater, Olin College, has a two-stage admissions process, and their Candidates’ Weekend includes a group exercise / interview that allows candidates’ collaboration skills to be directly challenged and observed.

A few people at the panel mentioned things they’d seen tech companies do to try to test collaboration skills in an interview:

  • Pair programming with candidates on prepared exercises.
  • Having employees work together with candidates briefly on the employees’ personal or open-source projects.
  • Having exercises where the candidate does a code review.

There were also a few mentions of things done to give candidates more of a trial period and mitigate the cost of leaving early if it wasn’t a good match:

  • Bringing on candidates as fixed-term contractors first.
  • Mitigating the financial costs of quitting (by paying employees who leave).

Some of those things might mitigate concern about “culture fit” when hiring.

Still, I think that when it comes to interviewing programmers, a somewhat mature methodology has been build up for judging programming ability, but the methodology for interviewing for collaboration ability still has a lot of room to grow.  What’s the FizzBuzz of measuring collaboration ability?