Pair Programming Interview

Tackling Java with a New Acquaintance

I recently interviewed with a company that adheres to the extreme programming (XP) methodology. It’s a part of the agile framework, and emphasizes pair programming as a means of producing higher quality code in a more timely fashion.

While I’ve pair programmed before, the meeting was my first experience pair programming in an interview setting, and I thoroughly enjoyed it! Any time I can write code, conceptualize code or discuss code, I immediately feel more at ease. And writing code alongside someone more knowledgeable, who is focused on helping you produce high-quality code made for an incredibly encouraging interview experience. It reminded me of one of the tenets of improv - “You can look good if you make your partner look good.” Not only did a walk away with a greater respect for the company and its process, but I learned a lot about the language and testing framework we used.

During the interview, I functioned as the navigator, reviewing the code, and providing ideas and direction for what we would tackle next. The interviewer acted as the driver, and wrote the code and tests. Since it was still an interview setting, I tried to be intentional about displaying knowledge I already possessed or gained through research in preparation for the interview. With that in mind, I focused on asking clarifying questions that revealed my existing knowledge. For instance,

JavaScript has an indexOf() method, is there something equivalent we could use here? If not, we could use a for loop to identify the element we’re looking for.

The company also focused on Test Driven Development (TDD), which actually made writing the code easier. Once I had identified potential test cases, and the driver had written the code to facilitate those tests, I’d had enough time to think through potential approaches and articulate a plan of attack to pass the failing tests.

Throughout the interview, the largest hurdle was identifying elements to refactor, in part because I was less familiar with the language. I could have done a better job of asking clarifying questions to clear up those grey areas more quickly. But after the first pass at refactoring, I became more familiar with identifying elements that were repetitive or could easily break and were good candidates for refactoring.

From that experience, I walked away with the belief that the XP methodology does foster communication, simplicity, feedback, respect, and courage. And, even if I don’t work in a company that adheres to that methodology, I hope to find one that also values those!

^{In other exciting news, a new kitten has joined the (extended) family!!}