Pair Programming for Interviewees

#interview #pairprogramming #juniordev

This post is a preview of the content that you'll get on my upcoming newsletter, Break In--resources for people trying to break into the tech world, by devs who have been there before.

What is Pair Programming?

"Pair programming" is something of a catch-all term. Any two (or three, maybe four) people working together to write some code qualifies as pair programming.

There are many different approaches to pairing. You might adopt the "driver/navigator" strategy in which one person does the typing and the other person dictates the direction of the code. You might try "ping-pong" programming in which one person types for a few minutes, then you switch and let the other partner take over.

While there are many approaches to pairing, the goals are usually the same:

Two brains are better than one. When you have two people strategizing together, they'll come up with a more robust and elegant solution that one person alone.
Spread the knowledge around. When two people are responsible for building a specific feature, its easier to spread the knowledge of how that feature works to the rest of the team. This makes it easier to grow the feature, refactor it or rebuild it in the future.

So, why are more and more interviews requiring you to pair program? Read on to find out!

Why Is Pairing Part of the Interview Process?

There are two reasons why pair programming has become a popular interview tool:

Pairing is a common and useful tool that you'll likely use in your new job as a developer. Many companies naturally want to see how you perform when pairing.
Pairing is a great way to learn how a candidate thinks and what they're like to work with.

Let's explore this second reason a bit further. Programming is all about solving problems. In your role as a developer, you'll work together with team members to fix bugs and build new features that meet the specific needs of your users in an efficient manner. Your potential future teammates are trying to find out what it's like to solve a problem with you, because that's what you'll be doing in your job every day.

They want to know how you break down and come to understand the problem or the task at hand, how you think through possible solutions and what its like to colaborate with you throughout that process.

Pairing is a great way to answer these questions about you, the candidate.

What Does Pair Programming Look Like in an Interview?

The manner in which you will be asked to pair with other developers during your interview can vary. Here are a few common options:

Build out a sample feature on either a simple app set up for just this purpose.
Build out a sample feature on the company's code base.
Solve a code challenge together like something you might see on the Euler Project.
Hunt down and fix the bug presented to you in a given code base.

Although the specific challenge you are asked to pair can be different, the overall approach to crushing this part of the interview stays the same. Let's find out how to win at pair programming!

How To Pair in Your Interview

There are a few strategies you can use to ace the pair programming interview:

State what you know
Ask questions
Start Simple
Write tests

State What You Know

When the challenge is first presented to you, it can feel overwhelming.
Start by repeating back to the interviewer what you understand the challenge to be. This will help you to clarify your understanding of what you're being asked to do. It will also give the interviewer the opportunity to offer you more information and start collaborating with you right off the bat.

Remember that a big reason why you are pairing during your interview is so that your future teammates can find out what it's like to work with you. So give them lots of opportunities to do just that! Stating what you know right away will provide your partner a chance to immediately provide feedback and help you better understand the task at hand.

Once you've stated your initial understanding of the challenge and begun working together with your partner, it probably won't be 100% smooth sailing. You'll start to work on a solution, realize another problem or a greater degree of complexity, and have to expand your solution from there.

These moments are a great time to fall back on the "state what you know" strategy. Repeat out-loud what your solution accomplishes so far, and repeat out-loud what challenges you still need to solve. This does three things:

Demonstrates your understanding of your code and the challenge to your partner
Allows you to take a step back and see problem more clearly, making the solution more readily apparant to you
Provides your partner an opportunity to jump in and offer their own ideas and solutions

Ask Questions

Stating what you know goes hand-in-hand with another strategy: asking questions. You can follow up statements about what you know with a question about what you don't.

Pair programming is all about collaboration. Your future teammate wants to know what it is like to work with you and learn more about how you solve problems.

Pair programming is NOT about quizzing you, putting you on the spot to prove your knowledge or catching you off guard.

So, ask lots of questions! Ask your partner to give you examples of how a usermight interact with the feature you're building; ask them to clarify what they mean by a particular statement; ask them if they have any ideas or preferences of where to get started.

Asking questions does a few things for you:

Allows your partner to understand how you approach a given problem
Allows your partner to collaborate with you by providing answers, ideas or follow up questions
Gives you the additional information you need to solve the problem

Start Simple

When faced with a complex challenge, like solving a logical puzzle or building a new feature, it can be easy to jump to the most complicated scenario first. Resist the urge to start building a solution that will address all the requirements or potential scenarios of the challenge before you. Instead, break the problem down into the smallest possible parts and start with the most simple scenario.

For example, let's say your pair programming challenge involes solving the Project Euler problem, "Multipes of Three and Five".

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000.

Instead of trying to find a solution for "all of the multiples of three and 5 below 1000", start with the example provided. You know that the answer for all the numbers below 10 are 3,6,6 and 9. So, write some code that spits out those numbers when given the number 10.

This will give you somewhere to start, allow you to get to work with your partner and give you a deeper understanding of the problem at hand. This understanding will allow you to expand your initial solution and solve the problem.

Write Tests!

Not every pair programming challenge is a good fit for this piece of advice. However, whenever possible, write tests for your code! This is an important strategy for a few reasons:

Testing allows you to think through the different possible scenarios that your solution should address
It allows you to test your code (obviously). Testing is often over looked in interview pairing but its an easy way to make sure that your code behaves like you expect it to.
It impresses your interviewer. Full stop.

You Can Pair Program

The pairing challenge can be an intimidating part of the interview process, but it doesn't have to be.

The most important thing to keep in mind is that this section of the interview is designed for your potential teammates to learn what its like to work with you. They want to collaborate, they want to ask and answer questions and they want to have fun.

By adding the strategies outlined here to your toolkit, and you can ace successfully illustrate your problem solving skills, effectively collaborate with your pairing partner, and ace this part of the interview.

Good luck!