Here at Catchpoint, we are growing like crazy. Since I manage the engineering team, I’ve been running a lot of technical interviews as of late. There are two main questions to answer in an interview, whether it’s for a technical role or not:
- Is the candidate a good fit for the role?
- Is the candidate a good fit for the company?
What many interviewers forget is that the interview is a way for the candidate to judge fit, as well.
In my opinion, leaving a few minutes in the end for questions is important. Bombarding the candidate with question after question is not a good way to handle an interview! People freeze up and start to second guess themselves. They become nervous and uncomfortable, and they don’t have the opportunity to address any of their own concerns.
Most importantly, they don’t act the way they would if they were to join the company.
A Technical Interview Is Not Just About Skills – It’s a Conversation
Being in engineering, most of the roles on my teams are highly technical. There is no doubt that the interview panel will get into the nitty-gritty to make sure that the candidate has enough technical expertise to succeed.
A lot of people can answer technical questions. But that doesn’t mean they are a good fit for the team or the company. Even worse, they might start at the company and then realize they don’t want to be here.
Forbes says that 17% of new hires part ways with a company within their first three months, mostly as a result of poor onboarding. Why not start the onboarding process even before the interview process is complete?
For me (and for my teams), an interview is a conversation. The goals are still the same, but I try my best to make the candidate feel comfortable. Were they a couple of minutes late? It’s not the end of the world. Did their microphone not work for a bit at the beginning? Happens to all of us. And yes, I’ve had my children interrupt in the middle of virtual meetings too.
The Importance Of Values
At Catchpoint, our company values run deep. We don’t just list them on our website. We live them. They’re part of our everyday lives, our performance reviews, and certainly our technical (and other) interviews.
I want to hear details about what each candidate does, and how they reflect personal values – and the values of our company.
- When I ask about projects worked on, I want to hear about customer impact. Delivering value is the name of the game. I want to see that the candidate is thinking about customers (both “big C customers” and “little c customers”) in their work.
- I want to hear about empathy, mentorship, caring, and humility. What are candidates doing to help others around them?
- Finally, I want to see how they solve problems. If I’m interviewing for a junior position, it’s OK that the candidates haven’t solved complex or high-profile problems. What matters is the process. Break down the problem. Explain it to me. Tell me about options. Why was it hard? Most importantly, what did the candidates learn?
Provide Real-World Scenarios
By the time the interview is over, I want candidates to understand what it will be like to work at Catchpoint, in this specific role. The way I do this is through scenarios. Candidates: Pay attention to these scenarios – they’re real-world examples of what other team members have had to deal with!
For a QA role, for example, I might ask about how candidates could go about testing a particular component that they’ve never heard of. I want to hear questions! This is new material, and it’s supposed to be. They shouldn’t simply guess. Instead, they should get enough information from me to answer the question, just like if they were working here and needed to collect information from a developer or a product manager.
For a developer role, I might ask about designing a system that looks, at a high level, a whole lot like the one they’d be working on. Again, I’d expect them to ask questions, as well as tell me about the challenges, options, and constraints. This commentary shows me how they think as engineers.
I may ask about solving problems with other teams. Again, it’s less compelling for me to be regaled with stories about problems that were solved easily and made the candidate the hero of the whole company. I’d rather hear stories about problems that were hard, took collaboration between several people, and maybe even failed. It’s the process and what was learned that matters.
Questions, Questions, Questions
At the end of the technical interview, leave lots of time for candidates to ask about anything that isn’t clear. They’re making a huge life decision. I want it to be the right one, just like they do.
Sure, I’ll answer the “can you explain how your RUM product works” questions, but honestly, is that something that’s going to impact a candidate’s decision? I’d rather hear ones that will influence candidates’ feelings about the organization.
The questions candidates ask during an interview generally won’t sway my decision. That part of the interview is completely for folks to explore the role and the company, and to add color to the conversation.
All’s Well That Ends Well
Hopefully, the process ends with an accepted offer and a long and fruitful partnership. At the same time, at the end of a technical interview round, my main goals are to understand how the candidate fits into the role and the company and to ensure they understand the same.
If all goes well, we’ll both be happy with the results. In the best-case scenario, the candidate and I can look forward to the “welcome aboard” email when they join the team.
Check out Catchpoint’s open positions today. Who knows – maybe you’ll get to see how the technical interview process works for yourself!