Having both taken a fair number of interviews as well as conducted them, I wanted to write a blog that weighs the value of different interview approaches from both points of view.
TLDR; Do I test coding or not?
In my opinion, yes, at least some coding should probably be done. However, conducting code challenges in a reasonable and consistent way is of the utmost importance. What the entirety of your process looks like will vary by seniority and from organization to organization, which is okay. What we really need less of in this industry is poorly developed, inconsistently delivered hazing rituals masquerading as good technical skill assessments.
How important is it to code?
Does a developer need to code during your interview process? From personal experience, I have felt I learn much more during the conversational parts of the interview, but need to see some code as a final gut check. Let me break down a few things I do and don’t think work consistently well.
Whiteboard interviews w/ code
I’m all for diagramming and architecture talks by whiteboard, but getting anyone to write code becomes painful. There are so many things that can go wrong in these situations that have nothing to do with candidate competency. It just doesn’t feel fair. I have both done whiteboard problems as well as conducted them. I have both felt hazed during a process and felt like I’m hazing candidates due to the dynamics of a whiteboard code challenge. I’m strongly against them, but I won’t outright condemn because there is no one-size-fits-all interview process.
Laptop coding with onlookers (in person or remote)
As I mentioned above, a lot of non-code related issues can stem from whiteboarding. One of them being that a whiteboard is not a keyboard. So our next inclination is usually to do a coding problem on a laptop. Laptop coding is a lot better than whiteboard coding, but all the other whiteboard problems can still exist. The unnatural tension and pressure that arise when having someone look over your shoulder can still be a bit of a bother. Different interviewers can also influence the code result depending on the level of hints provided. I’ve also had interviewers make incorrect or confusing observations that caused me to take pause.
These kinds of tests should not be confused with an assessment of the candidate’s pair programming skills either. It is not a natural day to day problem or conversation that you are having during the test.
I’ve found that take-home tests are both some of the fairest and most practical challenges to offer a candidate. Secondly, they turn out to be a great way to assess how much someone really cares about the job opportunity. If they forget to even submit the test or return you something very quick and sloppy, it tells you something. When they respond in good time with clean code and an email of questions/decision justifications it tells you something. I’ve also seen it demonstrate a Senior developer’s long-outdated knowledge of a platform that I’m not sure would have been as clear by any other means of testing.
Laptop coding - private work session
While I have not personally taken or conducted a private work session interview, it seems like an interesting balance between live laptop coding interviews and a take-home. If you don’t like the idea of someone going home and maybe seeking help or not being sufficiently time-boxed, then giving them a room to work in alone for an hour might be a good compromise. You may want to be prepared to award partial-points if the problem is hard enough to require close to an hour.
Technical interview questions
Technical interview questions are probably one of the most important portions of an interview process. As a candidate, I have felt the most heard as myself when I answer technical interview questions and as an interviewer, I’ve felt I learn the most about others. It’s hard to gauge what people are passionate about from code alone, but a technical interview question that leads to a strong answer or anecdote from a candidate can really help you see them more clearly.
Evaluating the GitHub Profile
I think a GitHub profile, or really any online presence can be a huge positive for a candidate. However, the lack of one tells you nothing about someone. At best it can be used for bonus points or a gut check but it doesn’t stand alone as a good evaluation tool.
Ask the candidate to show some of their code and discuss
Asking a candidate to talk through some of their own code is a great way to have a technical conversation and see some code simultaneously. In the past, I’ve paired this with a take-home test where the candidate speaks to their take-home code during the face-to-face interviews. I’ve also been asked during an interview to talk through some of the code on my GitHub that was 2 years old. It was a little scary, but the interviewer was open to me criticizing and suggesting improvements too. This is probably the right frame of mind to have if you will be putting someone on the spot to justify code they wrote a while ago.
Culture/Team-fit assessment interview
What does a team-fit assessment process look like? I can’t tell you precisely. Some of us are assessing team-fit the whole time, but others like to focus more deeply on how every new individual affects the culture and ask behavioral questions. I am not an expert in culture fit, but I don’t think it’s something easy to assess in a few short interviews. I agree that it matters, though. A weak or unmotivated developer on a team can distribute pressure to other team members which affect their morale and productivity.
If a hire ends up being a mess from a fit perspective, assess your interview process but also don’t be too hard on yourself. Not all bad fits reveal themselves immediately or reflect a fault in your process. This is one of those situations where the saying “Hire slowly, fire quickly” applies. If someone isn’t working out, you should have a probation policy to remove them quickly.
Developing a better interview process
With some of these considerations in mind, how do we put them together into an effective interview process? The details of an interview process will differ depending on the seniority of the candidate, but here are some guiding principles that carry through no matter what:
Start with interview planning
First and foremost, having a well structured and consistent interview process outweighs the value of any given question asked. If you don’t have an even ground to test people on, you’re not even trying to do your interview process well. It’s also not respectful of your candidate’s time to be ill-prepared. You’d be better off waiting a week to decide on your process, test it internally and refine it before the first interviewee even steps through the door.
Determine what you need
Try to be realistic about what kinds of problems you need this person solving day-to-day. Jumping straight to hardcore algorithms for an entry-level developer may be appropriate for some jobs if you want to have a really high bar to entry, but most likely you need to see someone functioning on something that looks closer to your codebase than a sorting algorithm. No specific level of technical difficulty will be appropriate for any given company, so this should be part of your interview planning process to agree on what matters.
Respect your candidates to get their best
Years ago I took an interview with a company that greeted me with a small welcome gift of a bottle of water, a couple snack bars and an interview agenda with each of my interviewer’s names, titles, and photos. It blew me away. I felt so valued by the process that I didn’t even care how it went after I left and wanted to recommend applying to other developers. In fact, I didn’t get the job but still took the time to thank them for making me feel so welcome.
While we don’t all have to greet our candidates with gift baskets, the part of the process that actually impressed me the most was the agenda. It showed a lot of respect for my time and candidacy. I felt more energized and excited for the interviews to follow.
Respect your interview process as you would your code base
If you currently have no interviewing policies for developers formalized at your organization, I would start by making a git repository and storing all documentation around your interview process there. Add all your questions, code challenges, etc… If the process needs to change, then formally introduce those changes in pull requests and discuss.
Treat those resources as the only process that your employees follow during interviews. Give every person on your team a place to go to be thoroughly briefed on how to participate in the interview process. When your process is consistent and strong, your candidates notice and it reflects on the passion for quality in your organization.