Find the right talent: Rethink the technical interview
Last year, I was tasked with creating a technical interview for PlaygroundXYZ. I was excited for this opportunity as it allowed me to bring some positive changes to this area of talent acquisition that I thought could use a little help.
I experienced many technical interviews over the years in my journey from a Junior Developer to Lead Engineer, and I have always found this area to be somewhat interesting. Although every company does it differently, they are all trying to reach the same goal: Find someone who is technical enough to pass the gauntlet that the company has laid out.
To me, that is where the problem sits. What happens if you have a great candidate that isn’t good at your company’s flavour of test?
Guidelines
I wanted to create an interview process that would be more effective in assessing a candidate’s skills and potential, so I came up with these guidelines for myself:
- Focus on how the candidate thinks. Completing the given task is merely a bonus.
- The candidate should have complete transparency. Don’t hold any information back at all — any question the candidate asks (even if they ask for the solution) is answered.
- Assess creativity and problem-solving skills. The task is open ended and has no “correct” answer.
- Even playing field. The same task is given to all candidates from junior to senior, with different rubrics to score expectations for their level.
- Empower the interviewee. Make them feel like part of the process. The candidate drives the interview by making the choices on what they’d like to work on. If they are not comfortable doing this, guide them through a general path.
- Use real world scenarios. The task should be similar to work they’re likely to see as an employee. Not everyone’s abstract thinking is the same.
- No tricks. No “Gotcha!” tasks designed to trip up the candidate; they shouldn’t walk away from the interview feeling worse about themselves.
The Interview Task
After considering the goals above, the technical task I came up with was to refactor an already working function that could be implemented better. There are many areas it can be improved on such as performance, scalability, and readability. The candidate is asked where they think it can be improved and to elaborate on why. After this discussion, they work on creating the improvements they want to do. Finally, we have a mini feedback session for both interviewer and interviewee.
The Interview Process
Personal Introductions
This is a good place to gauge how the candidate is feeling. If they are feeling nervous and respond well to chit chat, I spend a bit more time here to let them deflate. If it looks like the chat is causing more anxiety, I’ll pull back from the conversation and ask if they’re ready to start the task.
Task Introduction: Refactoring Challenge
Previously, I had set up a git repo with the technical task. Here I will ask them to clone the git repo and open it in their IDE or text editor of choice since I want them to feel comfortable coding in their own environment. I don’t see any issues if they rely on their IDE to get the job done.
Next, I ask them to open the main file and see if they can understand what the code is doing. I give feedback so they can gauge how close they were, then walk them through the codebase slightly more in depth. As a smoke test, I also get them to run the test file to ensure the foundation for the task is set.
If they’re stuck at any point, they can ask for help — I don’t care if they get stuck on a git command; I’m hiring problem solvers not git wizards.
Code Review Me
This is my favourite part of the process. At this point in the interview, I’ve connected with the candidate, and they have surface level knowledge of the task they need to complete.
I invite them to critique the code base. Every single line and file is up for critique. This is where you can get some really interesting insights. Some people focus on naming and documentation, while others focus on function signatures, implementations, testing, etc. You can sense what kind of code bases the person has worked on and what has shaped their way of thinking.
I want to know where they think they can improve the codebase, and what benefit they feel their changes provide. Again, no wrong answer — I just want to know more about how they think.
Refactor the code
Once the candidate has finished critiquing, I’ll ask them to refactor any area of their choice, and our interview invisibly adjusts to what they select. As they’re refactoring, I encourage them to ask questions for anything they’re unsure of, or even plain curious about.
If they manage to complete the task, I will add a few twists that could be encountered in the real world; things like scaling, statelessness, handling a larger volume of events efficiently, etc.
The goal is to keep pushing them with real-world requirements to think about, and see how they would think about that scenario. If they can’t think of a solution, I’ll give them small building block hints without giving the full answer away. If they still struggle, I’ll help them put the building blocks together.
Finishing Up
After enough time has passed, the hands on section of the interview ends, and I open the floor for any questions from the candidate. Quite often the candidate will ask for what I think the optimal solution is, and I’m happy to walk it through with them. If they manage to learn something during this section, that’s also a positive sign to me.
Once questions are over, I invite them to give feedback for the interview process, either during the interview or afterwards via email if that’s more comfortable. This step is important for me so I can tune the interviews for the future if necessary.
Closing Comments
A lot of information can be observed during this process that can give you implicit information about the candidate such as git experience, testing, technical knowledge of the selected language, and problem solving capabilities.
We’ve had a lot of success setting up interviews this way. It has really helped us find out which candidates were full of potential but may be lacking particular skills, and filter out candidates who were highly technical but struggled to come up with solutions for tasks they haven’t practiced.
Side note, I am neurodiverse, but it’s not something I tend to share before people get to know me (the irony of this sentence is not lost on me!). For people such as myself, an interview alone might already be a daunting task, and adding all these other technical interview curve balls does not help at all. I had to learn the hard way how to overcome this and interview well, but I don’t believe this is a skill anyone should have to learn. I feel we should look at the result (interview culture), the cause (tech interviews) and ask ourselves how we can make this a better experience for both sides.
