I have fresh memories of going through Atomic’s hiring process as a candidate. By now, I have had several opportunities to be involved in job interviews from the other side.
Our interview process for software developers involves multiple steps. This includes a written essay, a phone interview, a programming challenge, several face-to-face group interviews, and a practical pairing exercise. Each step has a particular purpose, and we continually experiment with the order and manner in which we conduct each step. Just as we strive to build great software and find better ways of doing it, we also strive to hire great software craftspeople and find better ways of identifying and recruiting them.
A Pair Programming Exercise
Pair programming—or “pairing,” as we call it—is one of our core practices here at Atomic. Developers typically work together in pairs for most of the day, nearly every day. So, naturally, the ability (or at least potential) to work well in a pairing situation is an important quality we look for in a candidate. We use the practical pairing exercise to get a sense of how the candidate would fare on the job.
For the exercise, we pair the candidate with one of our experienced developers to work on a mock project for an afternoon. Another Atom plays the role of the client. The client meets with the developers at the start of the exercise. They present the project requirements and can answer questions or provide clarification at any time. After a few hours of work, the developers meet with the customer again for an “iteration meeting.” In this stage, they discuss the progress made so far, and what the next steps would be if the project were to continue. The whole process is designed to simulate many aspects of what it is like to work at Atomic on a day-to-day basis.
Seeing Candidates in Action
The pairing exercise is an amazingly effective way to reveal key aspects of a candidate’s personality, abilities, and experience level.
Can the candidate interact and communicate effectively with their partner? Do they take the initiative and offer ideas of how to proceed? Do they wait to be told by their partner? Do they try to do everything themselves? Do they ask for help and feedback when appropriate?
Is the candidate someone that we could work closely with on a daily basis? How would being paired with them on a project for six months look?
What’s it like when the candidate communicates and interacts with the client? Are they comfortable asking and answering questions? Do they explore alternative solutions with the customer? Do they just do exactly what the customer says at first?
How does the candidate prioritize tasks and handle deadlines? Can they estimate the amount of time/effort a task will take?
Pay attention to how a candidate approaches a challenge. Do they break a large problem into smaller pieces? What parts do they tackle first? What technologies do they choose, and why? Is their approach novel and creative or run of the mill?
How skilled is the candidate with their chosen development tools and technologies? And, of course, how good are they at actually making software?
In many cases, the results of the pairing exercise turn out to be the main deciding factor in whether or not we extend a job offer. A candidate who looks great on paper might fall flat during the exercise. A candidate who seemed unremarkable at first glance might really wow us when we sit down and hammer out some code with them. In either case, the exercise reveals information that helps us make a better hiring decision.
Does your workplace use a pairing exercise when evaluating candidates? Have you ever done a pairing exercise when applying for a job? What was the experience like?