We at HackerEarth love pair programming. Before you call out for being biased though, hear us out. Over the years we have spent perfecting our interview platform FaceCode, we have heard from many hiring managers that pair programming is one of the best ways to assess a candidate’s coding abilities in real time.

Let’s look at what these managers have told us:

• With modern tools, employers must be well-informed about the coders’ unique skills set, ability to collaborate, solve problems, and strong analytical thinking
• Interviewers must be able to deduce the coders’ agility in coding, the complexity of the code used, proficiency in using features such as CodeEditor, auto-suggest, and much more
• A modern interview approach must evaluate how well coders handle ambiguity. It must highlight their attitude toward the challenge and aptitude for learning
• The interviewer learns about the interviewee’s skills and personality, while the interviewee learns about whom they will be working with and what a typical workday looks like

That’s not to say pair programming interviews can not go wrong.

Source: ASCIIville

DISCLAIMER: No known coders have been harmed during pair programming interviews. Also, breath mints are just good to carry along for any scenario. Just saying.

Laughs aside, the main reason why pair programming interviews go south is that the rules of engagement are not specified; or followed. As a wise man said, a football game without rules is just a brawl. So, let’s list down some of the oft-repeated mistakes in pair programming interviews and how one can avoid them.

Mistake 1: Not agreeing on rules beforehand

Pair programming has a simple structure. There’s a DRIVER and a NAVIGATOR. Simply put, the driver writes code while the other, the observer or navigator, reviews each line of code as it is typed in.

There are many ways this driver-navigator relationship can work:

• Ping-Pong pairing: In this Developer A starts the process by writing a failing test or the ‘PING’.. Developer B then writes the implementation to make it pass i.e. the ‘PONG’. Each set is then followed by refactoring the code together.

• Strong-style pairing: In this, the navigator is usually the person who has more experience with the setup or task at hand, while the driver has lesser experience (with the language, the tool, the codebase, or because they are fresh out of college). The experienced person usually ends up being in the navigator role and guides the driver.

• Pair development: Pair development is not a ‘style’ of pair programming per se. It’s more of a methodology. While the above two styles can be used for developing code in real time, pair development can be used to create a user story or feature. This goes beyond just coding, and allows the pair to handle many different tasks as a team.

So, before you invite a candidate over for a pair programming, ensure you know which style you are going to use and lay down the rules clearly. If you are switching roles between driver and navigator, make sure that the rules of discussion and expectations are clear from the get go.

Mistake 2: Lack of proper conflict resolution mechanisms

It is important that to settle conflicts well as a pair, and one way of doing it is to agree at the outset which role has the final say. Between the driver and the navigator, one role needs to have the ‘casting vote’.

That said, this mechanism should not deter either of the pair from asking questions, or raising red flags. The goal of the pair programming role is to provide the candidate with something close to a ‘real-world experience’, i.e. they work on actual problems that your team solves in their workday. At the same time, the interviewer gets a first-hand glimpse at the candidate’s problem solving skills, and ability to collaborate.

Don’t forget this in an attempt to be ‘right’ during your pair programming routine. Agreeing to a mutually suitable arrangement at the outset aligns expectations and provides a fairly straightforward method of conflict resolution.

Mistake 3: Thinking there is just one ‘right’ answer

There are 11287398173 ways to write FizzBuzz. Remember this when you are in the middle of your next pair programming interview.

As interviewers, a very easy mistake to make is to believe that there is just one right way to approach a problem. Experienced hiring managers know that while it is perfectly alright to usually have an answer in mind to a given question, it is also important to listen and see what the interviewee’s answer is.

Most of the time, you’ll find that the candidate’s approach is different from yours. If you keep an open mind, you might even be surprised by their creativity! Rigidity in thought is a no-no for any interviewer; this typically demonstrates that they are not open to new ideas and only serves to alienate candidates.

This is also important for interviewees. Many times, candidates get trapped in the rabbit hole of ‘pleasing’ the interviewer. They look for solutions that they think will appease the interviewer. It is important to be aware of this behavior. Use the opportunity to showcase your skill-set, instead of behaving like a mind reader and trying to say and do things that will impress the manager. Ask clarifying questions, understand the boundary conditions or the corner cases, and then do your own thing!

Mistake 4: Not communicating enough

Okay, we get it. Not everyone likes chatter when they are coding. Some coders like music, others like radio silence.

The whole purpose of a pair-programming interview is to communicate. Let’s rephrase that a bit. The sole purpose of a pair-programming interview is to communicate effectively with your partner and build something collaboratively.

Interviewers need to set the tone here. Please tell your candidates clearly what kind of communication you expect from them. Do you want them to finish their coding and then walk you through their code, or do you want a play-by-play commentary? While doing so, please be cognizant of the fact that you do not come across as intimidating, and allow the candidate the flexibility to understand and solve the problem in their own time and space.

Interviewees would do better to ditch the YOLO approach on this one and use the session to show their planning and communication skills.

Source: Google

Final thoughts

These are just some of the things we have learned from our discussions with hiring managers and candidates. We hope that they help you in your next interview. Another important aspect of a good pair programming interview is using the right tool, and HackerEarth’s FaceCode can help you with that. The key to having a good technical interview is creating a familiar environment for the candidates, so they can relax and focus on the task at hand. FaceCode, with its built-in code editor and easy-to-access question library, allows you to do that easily.

We hope you ace your next pair programming interview – whether you are an interviewer or a candidate. Good luck!

Kumari Trishya Author

An experienced wordsmith, she uses the power of engaging content to simplify the nuances of technical hiring. When not writing, she talks to her plant 'pets', and dreams of upgrading her home decor. A firm believer in the beauty of Sunday brunches, she loves gorging on chocolate cake and coffee, while reading a good Murakami or penning poetry.