The Technical Interview is an Ego Trip
Early in my career, after a short initial interview at a consulting firm in Toronto, I was invited to a technical interview on the same day. Two of the senior developers from the team I would join would conduct the interview.
The interview started pleasantly with them describing the project they have been working on: a portal for university professors to communicate with their students. It was being built with ASP.NET MVC, a framework I had been working with for several years. I expressed that I was comfortable with the framework and I would be excited to work on the project. Then the technical examination began and on its conclusion I left the interview feeling humiliated.
Many years later, when I was preparing to take an interview, I looked back on this experience to realize that the line of questioning and approach had been an ego trip for those developers. I promised myself to never make any of my candidates feel the way I did.
What did those developers do wrong? Leaving aside their attitude towards me, their questions had no relevance to the role or the project. I did not know what a red-black tree was at the time but I definitely knew how to use ASP.NET MVC which they did not inquire about.
My golden rule for technical interviews is that, "Every step, conversation and question must be pertinent to the day-to-day of the role." While this may be obvious, I am sure that many hiring managers are still expecting candidates to arrive at technical interviews with Computer Science books memorized. This form of technical interviews should be made obsolete.
Bigger button = more clicks on the CTA pic.twitter.com/Ter7xJdNKM
— Vincent Déniel (@vincentdnl) August 5, 2020
With my golden rule as guide, I conduct a much simpler interview process. Prior to an interview, my team and I review samples of code that the candidate shared with us (or had written on Github) to understand the quality of their code. And during the interview, I dive into three areas of discussions with the candidates: product building, process adherence and team work.
Product Building
I try to understand the candidate's interest and experience of building products by,
- Going through their past experience and asking about what technologies and products they built and how. I ask about previous products they have shipped from concept to market.
- To understand their thought process for deriving solutions, I draw an UI and ask them to outline and explain what approaches, structures and technologies they would use to build it out.
- I ask about how they keep up with technologies and how they improve their skills to gauge their passion for the work.
Process Adherence
To better understand how the candidate does their work,
- I go over their experiences and ask about how they managed their product-building and what tools and processes they used.
- I explain the process of working on our team and ask how they would change it and where they see inefficiencies to discuss their thinking.
- Often, I will give them a scenario where the processes are failing the team to find what they would do to tackle inefficiencies and if they would be willing to speak up.
Team Work
I also try to understand how a candidate works in a team,
- While going through their past experiences, I ask about how they collaborated and communicated with their teams.
- I present a scenario where their knowledge in an area may be lacking and evaluate if and how they would leverage and collaborate with their team.
- Another scenario I ask about is where they disagree with their team-members to evaluate how they manage conflict and focus on delivering results for the team.
I do this within one interview to be mindful of the candidate's time and mine. I want to hire candidates for their will to learn, grow and challenge the status quo.
The technology landscape is such that anyone can acquire a set of baseline programming skills. What is needed then, is a willingness to challenge ourselves and stay open-minded because every developer will have to learn on the job almost all of the time. Given this, the technical interview is arcane, academic and as good as dead.
