Interviewing and hiring at Pivotal

My current employer, Pivotal, practices the Extreme Programming (XP) software development methodology. One of the core practices of this methodology is pair programming: two engineers, two mice, two keyboards, two monitors but one computer and one task. Here's what a typical day of pairing looks like:

I won't go over the various methods for pairing here, but suffice to say this style of development requires solid interpersonal skills, even before we get into the balanced team approach that sits the engineers with the product managers and designers to collaborate together on a daily basis.

In what I think is a nice summary of this approach, there was a poster in Pivotal London's old office featuring Pivotal Labs founder and current Pivotal CEO Rob Mee with the quote:

"Software development, it turns out, is a team sport."

from What's Your Start-up's "Bus Count"? 7 Myths of Entrepreneurship and Programming

All of this means that there are plenty of great programmers out there who would not be a great fit for this working method, preferring to work exclusively on their own. Conversely, there are plenty of people who might not think that they are great programmers who have all of the skills needed to flourish as an engineer at Pivotal. As Pivots Are What Set Pivotal Apart puts it:

...being a Pivot means embracing the principles at the core of this approach. Pivots teach and learn from each other, demonstrating empathy, trust, respect, communication, feedback, and collaboration at every turn.

Pivotal hires, in short, for empathy. So how do they do that? There is a three-step process for hiring a new engineer at Pivotal:

1. Initial CV/cover letter screening or contact from a recruiter.

2. A short (30-60min) technical screening known as the RPI (for "Rob [Mee] Pairing Interview").

   This is a simple pair programming exercise where the Pivotal employee "drives" (i.e. does all of the typing) while the candidate "navigates" (i.e. figures out what the driver should type next). This is to demonstrate that the candidate knows the basics of writing code and also that they're capable of interacting with another engineer while doing so, describing their thinking.

   I found this a really good introduction to how engineering at Pivotal works, and the format makes it fairly low-pressure. By making the Pivotal employee the primary driver, it ensures that you can complete the exercise whether or not you're familiar with the specific language used (I wasn't); all that's needed is an ability to express the underlying ideas and engage in a discussion around the best way to accomplish the task.

3. A "day in the life" session at a Pivotal office.

   The final step is a full-day exercise, which generally involves two half-day pairing sessions, one with an engineer from the Cloud Foundry side of the business and one with an engineer from the Labs side (the hiring criteria are the same, I know quite a few people who've moved from one to the other). Where possible, the candidate works on real projects and solves real problems (or fails to, which doesn't necessarily mean failing the interview!) The idea is to make it as representative as possible of what working for Pivotal is like; this is as much for the candidate to get a sense of whether they'd like it as the other way around.

   Although a full day of pair programming can be exhausting, especially if you are new to it (as I was when I interviewed), I felt that the level of support you got from your pair made up for that. Again, if you aren't familiar with the specific technologies being used, they can do more of the driving while you help with suggestions on the direction the task is taking. As with the RPI there isn't too much pressure on you, unlike the typical tech interview, and you're actually demonstrating the skills you'll be using on a daily basis if you join the company.

   I have hosted a few interviews too, which entails introducing the candidate at the morning's office standup, taking them out for lunch and collecting any feedback they have at the end. One candidate recently described it to me as "the way [they] would want to be interviewed", which is heartening.

In all, I think it's a good approach that really reinforces the way that Pivotal works; it has certainly lead to great teams at the Pivotal offices that I've worked in (London and Dublin). By focusing on the skills you'll be using day-to-day rather than contrived whiteboard challenges or trick questions, it gives applicants from a broad range of backgrounds the chance to find out whether they would enjoy the work, while acknowledging the truth that skills in a specific programming language are often less important than the ability to pick up the one best suited to the task. In my view, it's a truly empathetic way to hire people.