Interview Potential Co-Workers
During your time at any given company, new employees will be brought on. You might be involved in this process, helping to vet potential candidates, or you might be in a position to establish a hiring process from scratch.
In either case, your job is to identify developers who can work well with you and your team. You need developers who can deliver results, just like you do. And it’s difficult.
In this chapter we’ll cover technical interviewing from two perspectives. First, we’ll outline what I believe to be an ideal process. I’ve been on both sides of this process and it’s effective and efficient at identifying good developers. After that, we’ll talk about other types of technical interviews that are less effective but that you might be required to conduct as part of an existing interview process. We’ll see how to get the most out of them.
Note that we’ll just be covering the technical interview portion of recruiting, as this is the portion you’re likely to be a part of. Discovering candidates, checking references, and other non-technical aspects of the hiring process are outside the scope of this book.
Ideal Technical Interview
Although each company and candidate are different, you can reliably follow a four step process to determine if a candidate is a good fit:
-
Informal technical discussion to meet and get to know the candidate
-
Have the candidate do a “homework assignment”
-
Conduct a technical phone screen
-
Pair program with the candidate in person.
Although you’ll want to conduct each step of this process consistently, you should take into account the role you are looking to fill as well as aspects about the particular candidate in question. We can place these two factors along two axes.
Along one axis is the candidate - how well do you know them? Have you worked with the candidate, and can vouch for them, or is it someone you don’t know at all?
The second axis is the organization’s need - the role to be filled. How much impact will this person have? Someone in a key position or on a very small team will have a much larger impact than a “rank and file” developer who will be building out features as part of a large, established team. Not everyone needs to (or should) have a huge impact, so it’s important to be honest about what you’re looking for.
For each step that follows, we’ll discuss if it applies to your situation (based on our two-axis approach) and if it does, how to execute that part of the process.
Informal Technical Conversation
This is exactly what it sounds like: a simple, human conversation between two professionals, “geeking out” about technology. The idea is to provide a relaxed environment where you can get a feel for who the person is as a developer. This should not be a harsh “Q&A” looking for esoteric technical knowledge. It should be informal and relaxed, but focused.
You want to make sure to cover the following things in your conversation:
-
What your company does and why anyone would work there
-
What problems the company has that the candidate might solve
-
What the candidate might expect to work on
-
The candidates thoughts on technology in general, but also related to what your team uses and what the candidate is familiar with
-
Interesting problems the candidate has solved and what excites them about the position
-
Any questions the candidate has about the company
For candidates you know, this is crucial. It lets them know that you aren’t treating them as just another résumé and that you have respect for them and their work. It’s also a good chance to “sell” the candidate on your company without starting a formal interview process.
For candidates you do not know, but who you’re hiring in a senior or key position, I would highly recommend this as well, because it’s one of the best ways to get a sense of them as a person, including their curiosity, personality, thoughtfulness and higher-level decision-making ability.
For candidates you don’t know, but who are being considered for a junior position, this is less important, and can be done as the last half-hour of an in-person interview, possibly with the candidate’s prospective manager.
Homework Assignment
Here, you give the candidate a coding assignment that they work on at home over a few days or a week at most. It should be a problem that requires more work than just implementing a function, but not so complex that it requires a huge time commitment. It should also be a problem that has many possible solutions but that you can evaluate easily.
The idea here is to examine the candidate’s code, when written in an ideal environment and not under pressure at a whiteboard or on a large screen attached to a laptop.
Be specific about anything you want the candidate to do, but keep in mind that every omitted detail is a chance to learn something about how the candidate thinks. For example, if you fail to document how you’d like the assignment submitted, you might get a .zip file, or you might get a link to a GitHub repository, or you might get copy and pasted code. This can be informative.
I would also recommend that you schedule the technical phone screen (discussed in the next section) when you give out the assignment. The candidate is going to spend his or her time writing code for you, for free, and you owe it to them to review it and have a conversation about it. Scheduling the phone screen is the best way to do that.
Finally, have a rubric for evaluating the work. It’s important that you evaluate every candidate’s work fairly and equally, which can be tricky for subjective attributes such as code quality. A rubric makes sure you check everything and don’t over or under-weigh aspects of the solution.
For candidates you do not know, this is a crucial vetting technique for any level. Candidates for senior or key positions should handle this assignment easily. Other candidates should produce quality results and can use it as a chance to shine.
For candidates you already know, this might be something you can skip. Candidates know that homework assignments are for vetting and “weeding out”, so giving one to someone whose abilities you are already familiar with can be seen as insulting. This could work against you by preventing strong candidates from continuing through the hiring process.
If you must give these assignments to everyone (it is often a legal requirement to be consistent in all candidate evaluations, depending on where you live), make sure to let the candidate know that, while you are sure of their abilities, your company requires everyone to do these assignments; it’s nothing personal. Of course, grade them fairly. On occasion, someone will disappoint you and it’s better to find out now.
Technical Phone Screen
The technical phone screen is crucial for candidates you do not know. It’s called a “screen” because the idea is to “screen out” candidates who will be unlikely to pass an in-person interview. Bringing a candidate in for a face-to-face interview is expensive and time consuming. The technical phone screen ensures that you keep those expenses to a minimum and don’t waste anyone’s time by bringing in someone who is unlikely to be a good fit.
A candidate you know and who is interested should be fast-tracked to an in-person interview if possible. In this case, a phone screen could be a barrier to hiring. If your company insists that everyone follow the same process (again, this could be for legitimate legal reasons), make sure to let the candidate know that it’s your company’s hiring policy and not a reflection on your respect for their skills. To be fair however, have another developer conduct the phone screen.
In any case, once you get the candidate on the phone, tell them your name, your position or title, what you work on (if it would make sense to them), and then outline the structure of the interview:
-
Technical questions
-
Discussion of the homework
-
Questions the candidate has for you
Technical Questions
Steve Yegge has anexcellent post about technical questions to ask during a phone screen. I’ve used his technique on many phone screens and find it effective at identifying candidates who are knowledgeable.
He asks five questions that cover a wide range of computer science, each designed to test for what he feels is basic knowledge any programmer should have:
-
Write some code for a simple problem
-
Talk about software design
-
Demonstrate knowledge of scripting languages
-
Demonstrate knowledge of data structures
-
Demonstrate basic understanding of bit manipulation
These might not make sense for your or your company, but pay attention to how they are organized. These five types of questions cover a very broad range of programming knowledge, from high level design, to low level bytes, to pragmatic use of scripting languages. Design your phone screen questions similarly and always use the same ones each time. If you find candidate are passing your phone screen but failing the in-person part of the interview, ask more difficult questions in the phone screen for future candidates.
As you talk, be sure to write down the candidate’s answers. Don’t just check “got it” or “missed it”. Describe what their answers were. The reason for this is that if a candidate does well but doesn’t nail the in-person interview, your notes from the phone screen might help make a final decision.
Discussion of the Homework
The candidate spent time on the homework assignment and deserves to have it reviewed by a developer. Discussing code is also a great way to get a feel for how the developer thinks and approaches a problem. If you haven’t already reviewed the candidate’s homework (I recommend the reviewer and phone screener be the same person), do so before the interview.
You should have a list of questions and comments about the code, but first get the candidate talking about the assignment. What was their approach? Was it easy? Challenging? Confusing?
Once the candidate has given you their overview of the assignment, go through your list of questions and comments. Be sure to praise anything you liked about their solution. This will make discussing negatives easier, but will also demonstrate that you value good work and will openly praise it (a selling point for you and your company).
Keep it casual and avoid any divisive arguments. Your goal is to understand how the candidate thinks when solving a problem, not to prove that your particular solution is the best.
Questions the Candidate has for You
When you’ve got what you need, it’s important to let the candidate ask questions of you. The candidate will certainly be curious about the company and you can use this time to “sell” them on it.
Be sure to be honest with your answers. If you are asked about something that wouldn’t put the company in a good light, be honest, but put a positive spin on it.
I worked a job once with almost 100 applications in production. One of the older applications had a very challenging codebase that everyone ended up having to work with for various reasons. When a candidate asked me about, I was honest: the codebase is not fun to work with. But, I turned it into a positive: management knew about the problems and was in full support of the team porting or refactoring the problem areas.
Once you’ve answered all the candidate’s questions (or the time is up), thank them for their time, and let them know that they’ll hear from someone one way or the other. If they did exceptionally well, and you’re sure you’d like to meet in person, definitely let them know. If, on the other hand, they did poorly and are unlikely to be called in for an in-person interview, keep that to yourself and discuss it with your hiring manager, recruiter, or simply sleep on it.
Pair Programming
When a candidate comes in for an in-person interview, or otherwise has passed the phone screen, you should be confident that the candidate can code and can work on the team. The last step is to find out for sure.
The best way to find out if the candidate can really code and really be a part of your team is to pair program with them. You should do this for every candidate, regardless of position or previous experience.
In a normal pair programming scenario, the two developers equally divide their time between typing code and watching the typer. For the interview, I would let the candidate do most of the typing. This will be most comfortable for someone not used to pair programming, but is also a good way for you to evaluate them, since your head won’t be in coding, but in observing them navigate the problem. I’d recommend you have them bring their personal development laptop to the interview.
As to the problem to work on, it depends on several factors. If you are a small startup, or are hiring someone in a key position, I would recommend spending over an hour on a real problem (or as real as you are comfortable with). Working on a legitimate problem you yourself might have to solve will be the best way to see how the candidate performs.
For larger teams, or for hiring more junior developers, I’d recommend using a simpler problem that can be solved in about 30 minutes, and use the same problem for everyone.
In either case, you want to allow the candidate to do whatever they need to in order to keep working. Allow them to search the Internet, ask questions, look things up, or do anything else they’d be able to do if they really worked with you. This is a real-world simulation.
If the candidate gets stuck, give hints as necessary to keep them working. It’s better to get the candidate to a solution with help than let them struggle and use up all their time.
At the end of the programming session, you should have a good feel as to how this person works, and if they would be a good fit for the team.
Many companies use a wide variety of other interview types (which we’ll cover in the next section) but in my experience, actually coding with someone is the only way to be sure. The only better way would be to hire then for a one to two week project, but this is often infeasible.
Once you’ve taken the candidate through this process, your next job is to make a decision: do you extend them an offer?
Making a Decision
Once you’ve completed the interview process, you’ll need to make a hiring decision. If you did the entire interview by yourself, it’s easy: decide based on what you experienced. It’s more likely that you weren’t the only one involved. This means that everyone who did participate has some vested interest in the decision.
It’s also important that whoever will be assembling that offer (which will include salary and other compensation) has a strong understanding of the strengths and weaknesses of the candidate. To this end, I would recommend that everyone involved in the interview meet as soon after the candidate is done as possible and discuss the candidate’s performance.
Let everyone get comfortable talking about the candidate and weighing in on how they performed. Make sure you hear from each person. I’d recommend going around one-by-one and getting verbal feedback.
Next, call for a vote. Everyone should vote either “hire” or “no-hire” and everyone should vote at the same time. An easy way to do this is to count to three and have everyone give a thumbs-up or thumbs-down. Doing it this way prevents “anchoring” where people vote with the majority who might actually have reservations. You need the most honest feedback you can get.
At this point, anyone who voted “hire” should be given the chance to convince anyone who voted “no-hire” to change their vote. Allow for votes to be called for again but, once each person seems content with their vote, make a decision.
I’d recommend you make an offer only if everyone voted “hire”. This means you allow anyone to veto the candidate. The reasons are threefold:
-
It’s possible the “no-hire” is aware of a shortcoming that everyone else isn’t, but isn’t quite able to explain it. It doesn’t mean the shortcoming is invalid.
-
It’s safer to walk away if you aren’t 100%. There is more risk in a bad hire than missing out on a great hire. This is especially true of candidates who will have a large impact.
-
The team’s morale will start to suffer if their objections are ignored. Disregarding a “no-hire” vote sends a message that the employee’s participation in the process provided no value; you would’ve reached the same outcome had they not participated at all.
This is the ideal interview process. Many organizations have their own process, which interviewers are asked to follow. Even if you can’t conduct the ideal process we’ve outlined here, you can still get a lot of value out more “traditional” interviewing techniques.