How we interview tech job candidates at Typeqast
Job interview is a stressful experience for everyone. Whether you’ve just quit and looking for a new job or you’ve been actively approached by a recruiter, the felling of anxiety is the same once you get into that meeting room. We’ve all been on that side of the table with sweaty palms, nervously trying to impress an interviewer with technical skills and personal charm.
In Typeqast, we’ve interviewed more than 200 people in the last year. Some were just screened and rejected straight away, while others made it to the end of the process. Ever since we started recruiting the very first employees, we made one thing clear to ourselves: we will do everything we can to make the interview process at Typeqast as stress free as possible. Unlike so many other companies in tech industry.
All of us who participate in interviews know very well how it feels to be on the other side of table. We’ve all been there, some of us many times. We know what scared us and what irritated us to a level where we would have just wanted to get up and leave the room. There are things that became a norm in tech interviews that every interviewee feels uncomfortable with and loathes. So why do it? Just because you put people in a high stress situation during the interview does not mean it will produce the best candidate. I would argue over this with anyone. Day-to-day software development is not a stressful experience, contrary, it’s quite an enjoyable creative job. So why do so many companies artificially induce stress and anxiety in candidates during interviews, only to (allegedly) show how they function in stressful situations? That makes no sense. People thrive only in stress free environments. Basic psychology teaches us that. If working in your office is anywhere near that nerve wracking interview, then sorry, you have bigger problems.
At Typeqast we make sure that the following criteria is met when interviewing people:
- Verify cultural fit of the candidate
It’s a paramount that people fit into our team’s culture and share the same values. This takes precedence over any technical skill. Cultural fit can best be checked in face-to-face talks. We want to see how people think and why. Situational questions and questions like “explain your biggest failure” can tell you a lot about the person and the way they see the world. - Test only relevant knowledge for the position that the candidate will fill
We are not looking for super human nor we want one in the team. We are always testing people for the real-life skills we need. We also don’t believe in full-stack (that is from CSS to database) type of developers. We know exactly which specific role the person will be filling and we focus our technical evaluation on that only. Playing with Golang and Blockchain at home is cool, but it won’t help you get the job with Typeqast. You have to be strong exactly where we need you to be strong. Everything else is a plus, but essentially irrelevant. - Algorithmic questions are useless
Knowing to explain self-balancing binary search tree means nothing if you can’t debug a simple app in the browser console. So relevance is the key. No one will be writing a new array sorting algorithm once they join us, so why even require people to know that. We don’t ask algorithmic questions from people who won’t ever write a complex algorithm in their life. It makes no sense and brings zero value. - CVs are worthless
Other than helping us do the highest level filtering in the very beginning, we believe that CVs give no value to candidate evaluation. CVs are just pumped-up sales material for a candidate and we all know half of the skills within are either made up or over exaggerated. We don’t bother with formal education neither. You either know the job or not. Fancy diploma does not change that fact. - Test the candidate’s relevance today, not what he was expert in years ago
This applies mostly to older candidates with years of experience. We don’t care if you were Windows 98 guru, we want to see where you’re strong today. Software engineering is a fast-paced environment. If someone is not constantly catching up with technology, his expertise from some years ago is pretty much useless today (other than in gaining life experience). - Knowing programming foundations, not the framework
We see this a lot with JS developers in particular. Good number of them know how to create a functioning React or Angular app without understanding basics of JS language and its environment. And that’s bad. We want people who understand the foundations of the technology they are using. People who started from the bottom and built their knowledge all the way up to the framework are usually the best and the most versatile engineers. And tomorrow they seamlessly switch to a new framework of choice. - Making interviews stress free
We aim for our interviews to be a pleasant experience for the candidate. We never put people in awkward situations, bombarding them with pseudocode writing tasks in front of a whiteboard. Whatever we want to find about the candidate, we can do it by simply talking in a laidback conversation over a cup of coffee. - Giving people enough time and space to show what they know
In most cases, we let people solve technical assessments at home while not being limited by time. Asking them to write code in front of others in the room while the clock is ticking gives no value to the process of evaluation because that’s not a real-life situation. What indeed is a real-life situation is putting your headphones on and taking your time to write good code. That’s why we do it that way.
Typical interview process for a technical position at Typeqast is a 3-step process:
- Screening interview
Screening interview is the first step in any interview. Unless a person is unable to come to the office, it’s a face-to-face talk with usually one interviewer. It typically takes 45–60 minutes, but not longer. The purpose of this interview step is for us to see if it makes sense to even proceed further with the candidate. What we are looking for is technical relevance (on a high level) as well as experience with previous companies, technologies, team setups, etc. This is good place to scan person’s cultural fit as well. - Technical assessment task
If the candidate passed the screening, he gets the technical assessment to solve at home. Based on the role (design, JavaScript, .NET, PHP, DevOps, Java, etc.) we have different tasks. They also vary by complexity, so juniors will get a different one than someone who is applying for a lead developer position. Once people solve it, they send us the link to their repo and we evaluate their solution. Evaluations is always done by at least 2 people to avoid bias. - Technical interview
This is essentially the last step in the process. If we are happy with the assessment task solution, we invite the candidate for a technical interview to defend their solution. That is a highly technical talk about their solution and general technical expertise in the given field. These talks usually take maximum of 2 hours. We believe that if we can’t scan someone’s technical skills in 2 hours, there is a problem with how we interview, not the candidate. People should not be tortured in interview rooms for hours just to prove that they have a gap in knowledge. Everyone has. We can easily see that within the 2 hour frame. These interviews are also done by at least 2 senior members of our team.
After this last step, we do a debriefing straight after the interview to compare notes and at this point we should have a clear enough picture if we want this candidate to join us or not. We tend to keep it very straightforward and realistic, with less philosophy and more pragmatism. In the end, it’s not about finding the candidate who ticks all of the boxes, but the one who ticks the most important of them. Interviews can be organised and executed not to be a nightmare experience, and that’s how we try doing it.
If you would like to join Typeqast team, we’re always looking for interesting people and good engineers. Check out the open positions.
