My interview process typically involves just trying to get to know someone to see if we're a good match culturally. After all, if you have a good mind for development, I know you'll be great if we can put you in the right environment with the right culture. As a result, I tend to spend a lot more time talking about what kinds of problems a developer finds interesting, what sorts of roadblocks she finds frustrating, and what technologies we have in common.
There is, however, still the necessary evil of seeing how far along the candidate is on the programming journey. To that end, I usually try to do a very basic code challenge. Normally it's something simple enough that we can still have a healthy conversation while we solve it together as a pair, and it's not so academic as to be useless in real life. Mostly, I just want to pair together to solve a problem.
I give the candidate the opportunity to select the language of her choosing and typically I'll know it well enough that we can pair to solve the problem. I explain the challenge, we set up unit tests, write a failing test, and make it pass. Sometimes, if I don't feel like I know enough, I'll change it a little and we'll try to adapt to the changes together.
This has been such a positive experience for me (and for the candidates I've talked with after their interviews), that I've spent a fair amount of time practicing the process. As I recently discovered, it's such a fundamental part of my interview, that I was completely unprepared when a client asked me, at the last minute, to step into an interview to do a pairing challenge with a candidate . . . who was remote!
Remote Pairing Interview
We tried to come up with a few options for doing the code challenge. After all, our shop pairs pretty much all the time and we try to be supportive of remote work. I mean, we've solved this problem before; however, it's seldom without hiccups. I know that candidates are usually nervous in an interview and I feel a lot of responsibility to help set their minds at ease. To that end, I like to appear calm, collected, and organized.
We considered using tmate and vim. We talked about screen sharing with TeamViewer. We also thought about just letting this candidate work on a harder challenge, maybe something from Hacker Rank or Project Euler, and email us the solution.
Each of these had a downside. Tmate would give the dev access to my machine and I wanted to let them do whatever they wanted without putting my machine in his hands. Alternatively, his machine could host but I wanted to be able to get to the solution later. Screen sharing with TeamViewer isn't as responsive as I like when pairing, especially if I want to be able to help out rapidly. Also, I type in Dvorak and sometimes that's an issue (turns out he does too . . . by the way). The async challenges, while good, don't let us know if we'll enjoy pairing together.
I remembered, a while back, running across cloud9.io and playing with it a little bit. I thought, "hey, what if we just try this?" Cloud9 would give us a sandbox that we can work in with a full ubuntu virtual machine. The candidate can do whatever he wants to it, we can code, install tools, whatever. I said, "hey, give me a second . . . I'm going to try this Cloud9 thing . . . go ahead and get your account set up and I'll invite you to a project."
In about 5 minutes, the candidate, my co-worker, and I were pairing and running tests on our Cloud9 workspace. There were no security concerns, communication was simple, we still installed and used tmux and vim, we had a sandbox, I was able to save the code. It was a really great experience. Not only did we offer a position to the candidate, but the candidate has been happy on our team ever since. I consider it a sign of a good interview when a candidate takes a position and I think that Cloud9 had a lot to do with this one.
I've not used Cloud9 (or any web based IDEs for that matter) on day to day work. Unfortunately, I'm not really in a position to try it out on the free tier. At some point, I want to go ahead and get a subscription and see how well it works out for me. I certainly see the value of cloud based IDE services and I like the idea that the most expensive development hardware you need is a Chromebook.
Okay, so maybe that's a little hyperbolic, but not for long. We have pairing stations that we treat like cattle rather than pets. We can wipe it completely clean and have it up and running again ready to go in just a few minutes. The hardware isn't commodity, but it could be. In fact, it could just be a web interface to a virtualized instance and why couldn't that be accessed from a Chromebook, pairing station, laptop, tablet, or . . . maybe in a pinch . . . a phone? Personally, I like it and hopefully I'll get a chance to push Cloud9 beyond "hello world."