Why We Pair Interview

Written by Allen Cheung.

This May Sound Familiar

“Write substr() for me in order n time.”

If you’ve ever tried to get a job as a software engineer, you’ve undoubtedly come across the dreaded whiteboard interview: implement this function, and do it efficiently with a clever algorithm. Bonus points for esoteric data structures.

Unfortunately, these kind of academic engineering tests have become the standard way to measure an engineering candidate. It’s unfortunate because the vast majority of us do not spend our days whittling YAQ (Yet Another Quicksort) with markers on a white board; we build systems, evaluate frameworks, debug APIs, and only rewrite sort() once in a while.

It makes much more sense to test skills relevant to our everyday work.

Dramatic reenactment. [feat. @jackdanger and @daicoden]

I Heard You Like Computers

At Square, we try to solve this disconnect between the traditional interview and well, reality, by sitting alongside you, in front of a computer, and pairing with you through the problem. It’s a huge logistic improvement; after all, engineers rarely scrawl out code on a board, we type it into a text editor. Presenting a familiar environment helps alleviate some interview tension, and huddling in front of a glowing monitor is considered a generally friendly way to interact with fellow developers.

Having a compiler, interpreter, and runtime environment opens up the range of interview questions and allows for generally better engineering discussions. Instead of worrying about mismatched brackets and gotcha bugs (with the interviewer doubling as an archaic human computation engine), we’re free to explore engineery concepts like code structure, testability, maintainability, and real-world performance. Personally, I liken a good interview to a frank exchange of ideas, with both parties being able to learn from one another.

Not So Fast

As we’ve learned, there are some minor downsides and caveats. Pairing in general has a flow that takes a little time to get used to, for the interviewee but also the interviewer if pair programming is not already a part of the engineering culture. As in real life, staring at code for multiple consecutive hours becomes tiring, so it’s important to take small breaks to recharge.

And while some questions are neatly self-contained, some problems require a bit of explanation and domain knowledge, and they’re arguably less “clean” than the hypothetic sparkly white board. For these and a few other reasons, we still engage via ye old white board for FizzBuzz-type questions and more abstract software concepts.

Does this sound awesome?

That said, pairing does provide us with a data point traditional interviews have trouble capturing: cultural fit. Sure, every workplace attests to having a great work environment, but the main positive takeaway from whiteboard interviews is that you can enunciate. Since we already practice pair programming at Square, this becomes a perfect opportunity for you get a sample of the Square work environment, and for us to ensure that you will like our development style and techniques.

And by the end, each of us will have learned something new. That alone is worth the time and effort to pair interview, isn’t it?

Do you want to sit down and tackle real engineering stuff™ as a part of the interview? Check us out at https://squareup.com/careers. Allen Cheung - Profile *I've been down on apps - specifically, mobile apps - for a while now. Of course, I use and buy and enjoy them on my…*medium.com