About tech interview
One of the greatest holy wars in history is about interviewing engineers.
Should it be some coding task? Should it be on the whiteboard or computer? Should it be an assignment for home or in the office (or online)? Should it be about algorithms? How to conduct it and evaluate results?
This article might cause your 'righteous anger,' rage, or disagreement. Or, maybe, the opposite. In any case — don't take it as black and white, and if you want to adopt something, it might also not work for you.
Being a few times at both sides, candidate and interviewer (like, really a lot), I figured what worked for me well. However, my way is tough to scale, and it requires a lot from you as an interviewer.
But why is that an issue at all?
A technical interview is a very stressful process, and there is no guarantee that the result will be fair. It has a massive layer of subjectivity, and it is impossible to make it objective.
Many companies try to make it as objective as possible and as automated as possible. As a result, it scales well, but also it checks only narrow skills that might not be even relevant enough.
I am pretty sure that many of us had that humiliating experience on one or many interviews in our life. Which is another problem: people and their skills and experience are unique, but we don't want to adjust our processes to that uniqueness.
Once I said to myself that people aren't code and data, though I can't apply an algorithm to filter those who can deliver results. Then I reflected on why people hate coding sessions and eventually realized that the whole idea is ridiculous. Let me explain.
Our goal is to understand that person can deliver a solution to a complex problem: this is what we usually do. But what we are checking is that either person knows and can recall the proper algorithm under stress (each interview is stress), or they can figure it out on the go. That's it.
The tool is not quite precise for the target. For example, I saw tons of solid engineers who can pass interviews easily. Yet, they cannot write good software, and vice versa: many brilliant engineers who are failing or struggling with simple coding interviews, yet I would kill to have them around. This approach usually is good enough for large companies, but as with many things on that scale, it is heartless, sometimes stupid, and humiliating.
Another angle is that interview represents a company. If you're not paying enough attention to it, you have a high risk of gaining a bad reputation. Neither you nor company management wouldn't like to find out one day that candidates are avoiding your company, only because it is known that the interview process sucks.
I developed a few rules for the tech interview process, aiming for adequate results (find people capable of solving problems) while making it a safe space.
Candidates shouldn't write code at all. The only exception is if, by writing code, they want to explain something.
There are no wrong answers, or it is okay not to know something.
If a candidate doesn't know something, explain it, and explain why it is essential to know.
If you're unsure at the end, give a home assignment and then make another session focused on the result.
If it is a no, explain why and what is important to learn or practice.
Candidates have to get feedback and interview results immediately, right in the room.
It would be a good interview if the candidate learned something: for example about a pipe operator that, I hope, is going to be finally available, or maybe that he is brighter than you and you love it.
Bad interviews have many reasons
One huge reason is the fear of hiring someone weak. Therefore, I believe, all those tests. For some reason, it is required to know or find out quickly how to solve a maze or walk binary tree efficiently. Instead, it should be crucial to detect the ability to hear abstract tasks like: 'we need to resend failed messages automatically as soon as connection restored' and have the ability to transform it to the software that implements network state, retry mechanism, messages queue, etc.
Another big deal is ego. Unfortunately, especially when an interviewer is an intelligent but very young person, there is a desire to dominate in the room. This is just unacceptable. If you have to do an interview, please leave your ego outside.
Be gentle, explain mistakes, and focus on two things: what a person knows and what it takes to figure out the answer when they don't or after you give a hint.
Even if you still do a coding task, work on that together; you shouldn't care if a person can or cannot solve the problem under interview pressure; you care how they think while trying.
One more is the conveyor problem. When the interviewer doesn't give a shit. It happens when interviewing is an unloved part of the job, and the candidate is most likely not be in your team, when even if it end-up as successful hire, you might never see him again because of the company size.
You have this event in the calendar and pattern of an interview.
You have questions, and you know answers, so you behave like a robot, don't even bother to remember the candidate's name, not saying read carefully CV and feedbacks that your company might already have on that stage.
Why bother? You want to end it as quickly as possible and back to your project.
Can you imagine the worst candidate's experience?
My version of a good interview
First is you have to know the candidate.
If you have a chance, it is best to have time together before (a few days is fantastic!) the interview. Take the candidate to lunch or coffee and talk as much as you can in detail about the position. If it is impossible, do it via video call.
Try not to forget the name and working experience, look at social media accounts to see the candidate's interests, take notes about work-related stuff, try to understand activity in professional communities, and open-source.
Second, explain how everything will happen. It would help if you had done it on the previous step, but it is worth repeating.
Many companies do several steps in one or few days. As I described before, I love to make a decision very fast, after a few hours of talk. Still, sometimes it is not enough, and in this case, I prefer to give a home assignment, which means that result will be thoroughly analyzed. And we will have another discussion afterward, despite the result. I am committing to this: if you do homework, I do the best possible review. And then we talk.
You have to explain that this is not a lottery and there are no wrong answers; it is okay to do not know something, that your goal, as the interviewer, is not just to evaluate coding skills but to evaluate the experience, not in the sense of ages spent, but in the complexity of problems that candidates solved and try to predict what they can solve in the future.
Another part of it is to encourage asking technical questions about your projects. Remember that it is not just you who interview the candidate, but also they interview you. So the candidate should be completely comfortable to ask you some questions.
As well as judge the company by the interviewer's questions: if you're asking stupid things, the risk of losing smart people is very high!
I start with simple questions about the previous significant experience.
Usually, I ask to tell about the candidate's project, but in technical details. And when they mention some topic, I usually ask to go deeper and explain how it works. And this goes and goes like a wool ball thread.
Usually, it starts with abstractions and high-level things: frameworks and patterns and ends up on the language (JavaScript in my case) specific low level. All questions and answers are entirely code-less. Sometimes candidates use a whiteboard when they need to explain something. I use it to ask questions or give hints, which helps me express myself.
Maybe an example?
If candidates mention that they used React and Redux combination (considering the candidate is one of the decision-makers), I will ask a few questions:
— What alternatives you have been researching over this combination, and what are the outcomes
— How is Redux's bureaucracy is organized (because there is some, right?)
— What would you do or have already done to make your app a container for other apps that should share state with the host?
It is okay to have some questions answered poorly, like: 'we chose those libraries because of our skills at that moment,' but it is a red flag if all answers are without enthusiasm and deep knowledge of the topic.
As I said, it usually starts with abstracts, and then we go lower.
So, for example, answering about Redux-related tools candidate mentions something like Reselect, and here we are discussing how memoization works. Then, blink of an eye, and we are lower, where the candidate tells how closures work.
It is important to explain things that are wrong or unanswered.
Try not to dominate here, like, 'haha, this is so simple'. Keep being friendly.
I gave a wrong answer and got a poker face as a response a few times in my life.
Once after the interview, when I googled the solution and how stupid my mistake was, I understood that this tiny thing that never happens if you do the actual project costs me the position.
Today I am glad it did, but at that time, I was humiliated, and the only thought I had was 'what the fuck with you people?'.
Sometimes you have or want to ask a question to which you don't know the answer or are unsure.
First, it is okay to ask it, and second, state that fact. Then, try to find a solution together: you can search for an answer or write a few gists to check the answer. This will pull off a teacher mask from your face; instead, you will look like a human.
It is good to have a few topics unrelated to the candidate's experience. Usually, it is something that is called a 'design interview.' Of course, those questions are very subjective, but it is vital to check that having a big 'green field' project is not an issue, and the candidate can decompose large things into smaller pieces.
Usually, I already have my decision even before the design part. Especially if it is a 'no', if you've spent a lot of time at the 'main' part and it is a 'no', you can skip the design part and jump to the feedback.
Feedback is critical, and immediate answer is MUCH better than regular 'we will call/write you.'
I start with the answer. Just like that: 'Unfortunately, I (or we) will not recommend you to the next step, so it is a no,' or 'Thanks, this was a wonderful interview, and I would be happy to see you (of course after other interviews if any) in the team!'.
But then, please, have at least ten or better 20 minutes to explain why. It is essential to be honest: not sugarcoat things and keep ego hidden. Try to suggest whatever you can to improve the state. Sometimes it is books or courses. Sometimes it is a lack of basic knowledge in favor of frameworks: 10 years ago, we had a lot of jQuery coders (I was one of many), today we have React, Angular, etc., coders instead of frontend engineers. It is okay, I suppose, but just until some point.
Don't forget to be thankful for candidates' time and efforts and let them know that you know how it might be stressful.
Interview like that takes at least two hours, even more when candidates start feeling relaxed and have a lot to share.
It means either they care about what they are doing or they just like to talk. This type is very dangerous.
You might feel like they know everything, but they are just answering different questions and trying to move the conversation in their comfort zone. So you have to learn how to detect it. Sometimes until the very end of the interview, you still have doubts: is it 'yes' or 'no'. This is the case for the homework.
If you don't have any doubts, just finish it with an answer and feedback.
As I said initially, this doesn't scale very well, and you have to train yourself, and you might make some mistakes at first.
But as a reward, you will get:
— best cultural fit, because you don't delegate interview
— most brilliant people, because you don't reject early
— the perfect team eventually, because each new hire most likely be successful in the long run
Hard work brings the best results; that's simple.
Important disclaimer: if you read this and you perceive that I propose to underestimate algorithmic skills or people who are very good at it, you got it wrong.