Pairing During the Interview
I found that sometimes even good developers lock up when given the “code on a whiteboard” option. It makes sense to do a basic FizzBuzz exercise or talk through an architecture design but writing outside of an editor is odd for anyone unless they’re a professional interviewee.
If possible, I jump into a pairing opportunity. A few hours or a day of pairing on something can show a lot of details.
- How do they approach a code or design problem?
- Do they TDD?
- How quick are they to backtrack on a bad idea without investing too much time on it?
- What tools are they already comfortable with or experienced with?
It’s always interesting to see someone’s desktop and their setup. Or to see first hand how they utilize their time.
Here’s my recommendation for technical interviews. At this point, they should have spoken to someone for at least 1 hour attempting to assess their technical capabilities but usually it’s 30 mins talking about your company and 30 mins talking about the candidate. Before interviewing, come up several applications to design. The ideas can be fun and interesting down to ETL and data scrubbing. For instance:
- The Game of Life
- A service to grab music artist information from 4 different APIs
- Parsing some data from NYC Open Data
The long form technical interview will take 2-3 hours. Two people spend 30-45 mins each going over their own questions covering problem solving, language preferences, details on implementations in the past, thoughts on this or that, etc. Any or all of which could’ve been their co-worker’s work or their mentor’s preferences. Then ask them to sketch out, on paper or just out-loud, a solution to one of the problems from above.
In the last hour, you then ask them to build one of the solutions. By this time, they have already walked through two of the designs. They don’t have to finish, they just have to start and show off enough. This is where pairing comes into play. Work the problem with them. Let them drive and do most of the work, nudge them when needed. You’ll be a poor pair partner this way but at least you’ll be there to answer questions without letting the candidate spin. Which is one of the essential benefits to pairing. Another key insight will be in how they work the problem, discuss the design and implement the code.
Another technique I encourage is to setup the candidate as a contractor for 8 hours (1099). If they can take an entire day off of their current job to be your pair partner, great. If they can’t, how does 2 hours every night during the week or 4 hours over two days? If you’re going to be sitting next to this person for years to come, you should at least date a little before getting hitched.