When I was explaining our interview process to my colleague, I realised that my approach is very different from what standard tech interviews are usually about. It is probably different from what interviews in general all about. But I am quite sure the usual way is broken and we need to work on a better framework. I am going to share my approach and hopefully, you can get some inspiration out of it.
Background
At Snyk, we have multiple rounds of interviews. It starts with a phone screening covering some general aspects, goes to the first round done by the hiring manager followed by a home task assignment. After a candidate sends us a home task, we review it and schedule the next round - pairing. If everything goes well, there is one more round with a hiring manager again covering more cultural aspects and work details in greater depth. I am usually involved in home task review and pairing sessions and I am going to focus on the second one here. Because I feel there is an improvement in the whole hiring process we can do.
Home task and pairing
Are a home task and the following pairing enough to assess candidate technical skills? Well, it goes to a fundamental question: “What do you want to know?” The biggest problem in interviewing is labelling candidates good or bad. If your framework can be described as “Is the candidate good enough to work here?”, you are limiting yourself and I would say you are limiting your potential growth and company culture as well. A better angle is: “Can we benefit from a candidate's current experience and focus?” Because there is no such thing as a failed interview. It is more about whether a company can see the use of a candidate's skills in the current time. And whether the candidate can see the potential for whatever they are interested in (learning, growth, responsibility, money, status). So what am I trying to address during my part of the interview? My question to ask is: “Would I like to sit next to this person for 4 hours and solve a problem together?”
But you have to verify their skills
You may be still wondering whether this can cover all the technical skills like algorithms knowledge, database modelling, testing… Well, it cannot. And I am 100% sure it’s not a problem. Because by asking coding puzzles questions (aka leetcoding), you are not addressing problem-solving capabilities. At best, you are addressing “solving coding puzzles” skills and how good they are in remembering chapters from the “How to crack a coding interview” book. The same goes for all other tech stuff - unless you are writing quick sort every day, don’t ask them to write it. Think about what you do in your day-to-day life. What are the challenges? How can you solve them on an acceptable, mediocre and exceptional level? And how do you want to feel when you are solving them with your colleagues?
My approach
I have three main goals I have in mind while talking to a candidate: Be respectful Have fun Learn something new The main message here is to be on the same level as a candidate. I am not superior just because I am interviewing them. I bet we all have some terrible experiences from our past interviews where we felt pretty bad and useless. I don’t want to do this to anybody else. Therefore, I am not testing their knowledge. I am not asking them questions expecting one right answer. I am asking about their ideas and opinions. Nicely said, right? But how can you achieve that? One example from a recent interview. A candidate mentioned some changes they could do in their code and said they would need to make sure the performance is not impacted. I could ask questions like “What do you know about performance measuring?” or “What tools are we using to measure performance?”. But I said: “How would you measure whether it has a performance impact?”. By this, I allowed them to express both their opinions and experience. I can share some of mine as well asking them for feedback.
This setup greatly helps with the last learning part as well. I am not expecting any right answers, so we are rather talking and sharing our opinions. I can also learn a lot from theirs and I’m allowed to pass my experience to the candidate easily. It makes me happy when they mention they have learned something new during the discussion.
Evaluation
This all sounds very nice, but all in all, it is still an interview and I should be able to articulate an answer and reasoning, whether I am for having this candidate in a team or not.
There are two main questions I am trying to answer are: Are they able to understand and solve the problem using a programming language and other tools? Do I enjoy working with them?
The first one is kind of straightforward. During pairing, you can usually very quickly spot if they need to check documentation every single time for writing even simple language constructs. If they can catch errors and extract functionality to better encapsulate units. And I pay special attention to debugging. I don’t need them to have a full-blown debugger, I just expect them to navigate their code effectively and have a good way of identifying where the problem can be.
Whether I am enjoying our discussion is more tricky. The most important part is not to be pulled into any kind of bias. I am keeping in mind I am representing a company culture and I need to understand if they would fit in. So I am trying to uncover how easy or hard it is for them to accept a different opinion or a suggestion. How can they clarify and support theirs? How verbose are they when thinking about the problem? As a company, we have a very open and sharing engineering structure. A quiet person, who needs to think for an hour by himself would be probably struggling heavily. The same goes for folks who need to solve everything on their own, without using libraries or asking for help or clarification. So this part is not about whether I would go for a beer with the candidate (although, if they join, it is likely to happen too). It is more about their fit for our standard way of working.
Let's improve our tech interviews
I am heavily convinced a lot of people are passing bad interview experience to others. Because “I had to deal with that, so they have to do it too” approach. Or because they simply don’t know how to do it differently. I am guilty of doing this too. But I have decided to stop. I am stepping down from a superior interviewer position and model the discussion as we would be colleagues already. Since I don't want to make my colleagues feel uncomfortable, there is no reason I should treat candidates differently. Because they can turn into colleagues easily.
Thanks for reading. Do you have any questions or errors to point out? Or just wanna chat? Let me know on Twitter. Or add a comment on Hacker News.