The most important thing

Hiring is the most important thing you can do to build a great product and company. We've been lucky enough to help build teams at multiple global public companies. In doing so we've learned a lot about what works and what doesn't.

Hiring is something we discuss a lot at Rocket because we are always on the look out for exceptional talent. Additionally, our clients frequently ask for our help to define or refine their hiring process. We wanted to share what has worked for us. Of course, YMMV.

The process

The hiring flow is roughly divided into 4 parts:

• Phone screen
• In-person sessions
• Code pairing
• Group beer / coffee

Here is a description of each of these section.

Phone screen

They are 30-45 minutes. The hiring manager performs the phone screen. The goals of the phone screen are:

• Give the interviewee details on the position and a sense for what their day to day would be like. They are interviewing you as much as you are interviewing them.
• Get a sense for whether or not the interviewee has the technical chops to keep up with the team
• Determine if the interviewee has the right attitude to work well with the team

To accomplish this we maintain a spreadsheet that has a tab with 'phone screen' questions. By keeping a list of questions it helps ensure consistency across screenings.

We start with an overview of the position and hit the highlights of our tech stack/process. This helps set the interviewee's expectations. It also sets up the call as a conversation and not a one way firing of questions. Then we try to suss out how deep they have gone and if they have a passion for learning/getting better. Sample questions at bottom.

In-person sessions

If the person has passed the phone screen and there is interest on both sides to move forward then we proceed to an on-site interview. The on-site interview starts with 3 45 minute interviews. These are broken down in programming, architecture and UI (where appropriate).

These categories of questions hit all the different areas that a developer will need to know.

A single person from the interview team is assigned to each of these slots. Again, we will track appropriate questions in a shared spreadsheet. When a calendar invite is set-up for each of the slots we tell the interviewer what their slot is (programming, architecture etc.)

Pair programming

The pair programming is last part of the formal interview and is usually 3 hours and is done at our desks.

The technique that we use to determine this are pair programming sessions. We're huge fans of the code pairing. It helps us understand if a person can actually get stuff done. It also accomplishes the following:

• It's a more practical/representative of what the person will be doing on a daily basis than answering the big O notation for some search algorithm.
• So much of development is working together -- mentoring, problem solving, discussing alternative approaches etc. A pairing programming session helps you see what a person is like as you work through these types of problem. You just can't get it another way in an interview.
• We've found the pair programming section to be a great selling point for the interviewee. We do the code pairing section at our desk surrounded by our team. The interviewee gets to experience our culture, process and passion for great work first hand.

We always start off doing the coding while discussing problems and then after 15 minutes or so will hand the computer off to the candidate. They will work on it for a bit and then pass it back when there are natural breakpoints. We will continue in this manner.

For what to pair program on we ideally like to take a story off of our backlog. Sometimes there is not an appropriate story so we also have a stock list of interview questions as well. Examples at bottom.

Group beer / coffee

If everything has gone well we like to take the person out to grab a beer or coffee with the team. It's a good way for everyone to get to know each a bit better and further check if there is a 'cultural fit'.

Also, when you have a team that enjoys hanging out with one another, gets along and can have fun that is a selling point for most candidates.

Prep the interview team

Before the interview, get the interviewing team together and define the role and describe the ideal candidate. It's helpful if you can relate it to someone on the existing team. E.g., we are looking for another Anne. We then divvy up the categories (architecture, programming, code pairing) and assign them to each person on the interview team.

Don't waste peoples time

If part way through the interview it becomes obvious that there is not a good fit -- end the interview. It's a waste of the interviewee's time and your teams time to continue with the interview.

Thumbs up / down

After the interview we get together and discuss what we thought of the interview. Basically 'thumbs up or thumbs down'. Usually everyone needs to be thumbs up in order to proceed with an offer. The hiring manager always reserve the right to veto what the team says... but we hardly ever do. It's a sign of not trusting your team.

Example questions

Phone screen

(First half of these question give a sense for how deep a person has gone/learning/attitude, second half starts to dive into their technical knowledge. Obviously you need to customize the technical part to the type of developer you are looking for.)

• Tell me a problem you recently had to debug; how did you debug it?
• What is your favorite programming language; why? If you could add one thing to it what would it be?
• Is there a meet-up, book or blog you would recommend to me? Why?
• Optimistic vs. pessimistic locking?
• Can you explain closures? When would you use one?
• Frame, bounds, anchor points, position
• How can you track down memory leaks?
• How do you test your code?

Programming

• Write a function that iterates from 0 - 100, and if the current number of the loop is divisible by 3 prints 'ping', if divisible by 5 prints 'pong' and if divisible by 3 and 5 prints 'ping pong'.
• Write a function that will take a string and print out word frequencies for contents of string
• Write a function that 'debounces' a wrapped function

Architecture

• You are designing a system with redis, postgres and a RESTful endpoint. A call to one of your routes will hit all three systems. How do you keep things in sync given there are not tx's across the system?
• How would you go about using redis to build a system to roll out features to individual users, groups of users, and some percentage of users?
• Given a C API which gives access to an image, you need to incorporate this into a TableView which will show album art. How do you do this?

UI

• Look at the main screen of our app. How would you lay that out in CSS? How about from an angular perspective?
• Explain how a grid system works; have you used one of the popular grid frameworks? Why did you choose that one? How do they work?
• Do you use Storyboards? How would you animate growing a UIView?

Pair programming

• tic-tac-toe
• places api, table view, map
• redis, web sockets, update web page