Technical Interviews - A Revised Process

I recently attended a handful of conferences, some of which I’ve spoken at. A topic that is frequently discussed based on the research I’ve been doing in regard to the the benefits and challenges of being a parent and developer is technical job interviews. More specifically, people focus on the questions of what do companies ask? What do they expect?  And how well do these processes actually asses an applicant’s ability to do the job? One of the things I’ve found in my research is that parents have difficulty showing what they are capable of because they have less time to contribute to open source and side projects. The proliferation of take home code challenges as a response to the backlash against white boarding in interviews has solved some problems but created others. Giving a large chuck of focused time and attention outside of work hours to accomplish a code challenge is often difficult for parents, caregivers, or people who have significant outside-of-work responsibilities. As a result, I’ve done a lot of thinking and discussing about what an effective interview process might be, especially for developers with 2-3 years of experience.

I started by thinking about what I do at work. I refactor (a lot). I research (a lot). I learn (a lot). And I work through understanding code that other people wrote (a lot). What I don’t do a lot is code from a blank page. Companies always say that they just want to hire people they know can solve problems and can learn. From what I’ve heard, most technical challenges don’t really accomplish this. I’m not saying the methodology below is perfect but I think it comes closer to a solution where unconscious biases and the dependence on a significant amount of free time are less of a factor while still showing technical capabilities.

Here is what I suggest an interview process contain. Ideally this would be broken up into a short (1.5-2 hours or less) take home portion and an in-person or virtual conversation in lieu of a pairing session and/or take home code project. I think I see the first three items as ideal for a take-home portion and the last two as either take home portions with additional discussion or fodder for some fantastic technical conversations.

1. Breaking apart a problem or feature. 

One skill I find extraordinarily useful in my day-to-day experience is to be able to break apart a problem or feature. I’m often looking at issues and asking additional questions based on my knowledge of the codebase, and making sure that something doesn’t strike me as problematic within the context of a solution. An example to use in a challenge could be technical, but that may be difficult without a lot of domain knowledge. Keep in mind that an interviewer can also tell someone’s prowess for problem-solving by giving a candidate a scenario that is completely unrelated to tech. How do they reason through it? What pieces does someone highlight? What additional questions would they want to ask? If it seems applicable, what might a diagram of the solution look like? All of these reasoning come into play really often, especially for developers who have 2-3 years of experience, oftentimes a group that is looking to grow in this area and understand what additional questions and considerations more senior developers ask when solving a similar problem.

2. Research a topic, library, or other implementation strategy. 

This is a great one because we look at this stuff all day long. Developers hear about new tools at a meet up and think about if it’s applicable or if it could help their company in any way. During the day, developers are asked about a feature or functionality and want to see what’s out there and what might be worth implementing or do you want to roll your own? Having to do this research, including listing potential pros and cons, commenting not only on the result but how a candidate came to that conclusion is really powerful. A candidate could include what they read, where they looked, how they got started and more! They could also not include these things which would also be extremely telling in an interview. Ultimately, the “right” answer might depend on project context but this would tell the interviewer a lot about what they might do on the job and how much confidence you could have in something they recommended. Finally, one of the things I love about this question is that it is scalable to every level since you expect junior developers to evaluate possible items differently than a senior developer might.

3. Provide an explanation for something. 

Oftentimes at work, developers are helping to teach each other and learn from one another. I think great code reviews sometimes include a person commenting “what’s this?” or “I haven’t seen this design pattern before. Can you explain it a little further or provide some learning resources?” Most companies want to make sure they’re hiring a team player, someone who isn’t just writing code but contributing to an overall positive culture for a team. For this, I’d suggest a simple term (not some complex process that has lots of different polarizing opinions surrounding it), possibly something related to the company’s codebase that they’ve found new people coming in don’t have lots of experience with or that they need to be taught. Make sure to say it’s okay to google and use resources if a candidate needs to (I assume that a good answer to this question will likely site at least one or two different resources). As an additional consideration, I’ve talked about the importance of actually interviewing for mentorship if that’s something your company values. In this case, if mentorship and team learning is a company or team value, a company interviewing might ask for two different explanations… one that someone would provide to peers at a similar experience level and one that would be a more appropriate explanation to a junior or brand new developer. This is also a great way to get other people on the team involved in the interview process. Show a couple of teammates at these levels the explanations (without the candidates name, if possible) to see if they understand them.

4. Refactoring

We all know that this is what most developers do every day. We refactor. We solve bugs, we tweak features, and we refactor. I LOVE refactoring and I like to think most other developers do as well so provide that as a technical challenge, or even something to pair on. Provide either a method or a file with some code you, as an interviewer, would consider dirty, smelly, ugly, slightly confusing, or whatever other adjective you want to use for it and have the candidate refactor it. You can see their thought process when approaching code, you can probably have a really amazing conversation about this thought process, methodologies used to refactor, different ways of refactoring, and more. If you’re providing a file or more than one example, let the interviewee pick where to start. Again, while this can be a portion of a take home assignment, I think both interviewer and interviewee will get more out of the exercise if they’re doing it as a part of a conversation and it also helps the company interviewing be mindful of outside time spent on challenges.

5. Tell me what this file is doing.

Finally, the last item on this list is a blanket- what is this file doing? How many companies have big, complex monolith applications at this point? And how many times do you spend time during your work day working through code, figuring out what’s going on? This is another perfect example of something that can spark a great conversation, show an interviewer how a candidate goes about figuring these problems out (there are a variety of ways to do this) and this skill likely directly affects a person’s ability to accomplish the job successfully. Another super scalable activity because you can show files of different complexity levels to different candidates based on their number of years of experience.

Again, I’ve written these suggestions as good options for mid-level developer interviews, but, as I mentioned specifically in a few points, they could be altered slightly to be applicable for interviewing at any level. What do you think? If you interview, do you employ any of these strategies? If you currently depend on long (I define long as anything over 3 hours, even for a junior level developer) take home challenges, would these alternative “assignments” help you asses a developer more effectively when looking at their everyday responsibilities?

And if you do interview like this (or would love to test it out), I'd love to talk because I'm looking for my next great career opportunity. Get in touch.