Interviewing is one of the most important activities for an Engineering team experiencing growth. Hiring the right person will make your team stronger and add to your culture, while hiring the wrong person can be costly for your company and your team’s morale. People are the most important part of building software and we want to make sure we are doing everything we can to get the most out of the interviewing process. In Engineering, one important part of an interview that often gets a bad rap (and for good reason) is the technical interview. You don’t have to look very far to find horror stories of terrible technical interviews.

Many companies have traditionally relied on two main types of technical interview:

1. Whiteboard Coding
2. Stump the Candidate – see also Brainteasers, Puzzlers, Riddles

The problem with these types of interviews is that they don’t get to the core of what you’re trying to learn about the candidate. The best way to learn if a candidate can code is to have them code. I mean, really code, with a proper IDE and in a team setting. The technical interview is an opportunity to see how a candidate approaches problems and also gives them a glimpse into how your team works.

At Jama we have several goals for the technical interview:

• Give a sense of what it’s like working on our team – we pair program, do test-driven development, and collaborate on code and design
• Understand how a candidate approaches and breaks down a problem
• Understand a candidate’s communication and collaboration style
• Get an opportunity to talk about code, architecture and design
• Understand the pairing dynamics with various members of our team

Our Technical Interview

Our technical interview consists of a coding problem that the interviewing team tackles in a pair programming fashion with the candidate. We found that getting the right setup and structure for this part of the interview allowed us to dive right into an environment where developers feel most comfortable: coding, problem-solving, and talking about design. The following is how we roll with our Front End Dev technical interview:

The Setup

The physical setup for the technical interview consists of a typical pair/mob programming setup: a laptop hooked up to a TV so the interviewing team can participate along with the candidate. We use IntelliJ as our IDE at Jama and that’s what we use for the interview. We’ve found that it’s also useful to have a couple other IDE options available if a candidate is more familiar with Sublime Text for example. We want a quick start to the coding portion and we want to remove as many barriers to this as possible. We have a GitHub project for the boilerplate of our coding problem for a quick and easy start. We explain how the technical interview is going to work and give an introduction to the coding problem.

The Coding Problem

We use Conway’s Game of Life as our technical problem. If you are not familiar with the Game of Life, it is a cellular automation which consists of 4 basic rules. It is simple enough to understand and get started on, yet complex enough to have an infinite number of potential solutions and design approaches. There is no single solution that we’re looking for and the variety of different potential solutions and approaches to the problem allows us to learn about how a candidate breaks down and thinks about a problem. We’ve used this problem before when we’ve run internal code retreats (a topic for another blog post) on the engineering team and it was a natural fit for our technical interview problem.

An example of an oscillating pattern in the game of life (image from http://www.conwaylife.com/wiki)

Pair Programming

We want to give a sense of what it’s like working on our team, for us this means pair programming. We have found that pair programming leads to better design, better communication, and higher quality since it is a form of continuous code review. We do three 15-minute pairing sessions with a break in between to discuss how each session went. This gives the candidate the opportunity to pair with three different members of our team and to build on what the previous pair built. This is about the process and not the result, we definitely do not expect a fully working solution at the end of this exercise. We do expect to be able to pair up with the candidate to tackle different aspects of this coding problem in a collaborative and communicative way. For the pairing exercises we tackle the coding problem from these three different aspects:

1. Visualizing Pair – This pair develops a way to visualize the current state of the game of life.
2. Simulation Pair – This pair starts to implement the state and rules of the game of life. There might not be enough time to get through the full implementation but we can usually get a good start on the rules and we can revisit this later in the technical interview if needed.
3. Refactor Pair – This pair decides what and how to refactor with the current implementation. We also use this time to throw in additional rules or requirement changes to see how the candidate handles requirement changes.

Summary

I admit that we’ve done whiteboard coding problems and coding puzzlers at Jama before. Like many tech companies we quickly learned that those styles of interviewing were just not telling us anything useful about the candidate and didn’t allow us to show what it’s like actually working on our team. With our technical interview now, we’ve tried to closely mirror our working environment and get a good sense of what it’s like to work with the candidate. Since we’re tackling the same problem with every candidate in a structured format, we have a nice way to compare candidates in their approach, design solutions, and communication styles. We are familiar with the problem domain and we can help candidates get unstuck and move forward when necessary, after all, that’s just part of pair programming, right? We have also embedded pieces of our programming culture and domain into every part of the technical interview. This not only gives us insight into how the candidate would work on our team but also allows us to show off our engineering culture at Jama. We have found that by structuring the technical interview in this way, we are able to diffuse a lot of the pressure normally associated with technical interviews and we allow the candidate to quickly showcase their talents and approach to problem solving.

If you’re looking to revamp your team’s technical interview here are a few tips we’ve found useful:

Tips For Your Technical Interview

• Identify Your Team’s Core Values – Make sure your team is aligned around these and is looking for them in the interviewing process.
• Keep It Simple – Keep the programming exercise simple. We’ve found that the Game of Life is ideal but you may find something in your own problem domain that you can reduce to a simple problem.
• Repeatable – Create a repeatable, semi-structured interview format. You’ll want to compare candidates’ strengths and approaches while allowing flexibility to explore their unique experience.
• Keep It Real – Mirror what it’s like working on your team. Does your team pair program, write unit tests, use an IDE, code review? Then find a way to do these things in the interviewing process.