Conducting a Better Technical Interview: Problems and Solutions
As technological progress is ever so present, we begin to rethink what areas of our professional lives can be improved. A good example would be technical interviews — or, to be precise, the way they are conducted. When hiring the right candidate can make or break the company, both recruiters and developers put a heavy focus on technical interviews — but is it correct to do so?
Technical interviews nowadays have a whole culture built around them: manifestos like “Cracking the Coding Interview” and YouTube videos alike are all trying to decipher what the recipe for a successful interview looks like. However, technical interviews are often criticized for their arbitrariness which can lead even the perfect job candidate to failure.
The recruiter’s goal is to create an environment where the job candidate can really shine, but current systems of technical interviews (used both by large and small companies) often fail to provide such conditions. Instead, they put heavy constraints on both sides of the interview, forcing them to perform as quickly as possible and run the risk of making a mistake — in essence, technical interview starts to operate like a conveyor belt:
Candidate A, please start Task B — You have 18346 seconds — Your time is up — Candidate B, please enter the room.
The developer community, feeling dissatisfied with how their real-world skill set and knowledge are treated in these interviews, addresses these issues in numerous blog posts and studies. In this article, we will try and analyze which features of technical interviews are criticized, why, and how they can be improved.
Technical Interview Caveats
Throughout the years, various studies have aimed to analyze which aspects of the technical interview can be improved upon. Although these problems may seem hard to fix, we can at least pay attention to how we conduct technical interviews and take a look at the bigger picture.
No Industry Standards
With the rising popularity of IT-related professions, you’d think that the industry would agree on a set of standards to make the recruiting process easier for all parties involved. We wish! As of now, the technical interview aspect is pretty much random: job candidates are oftentimes forced to try and prepare for all questions known to exist. It can be attributed to the industry’s lack of consensus about dos and don’ts of the interview process: what other areas of knowledge (beside a candidate’s general expertise) can be tested? Is it fitting to include, say, abstract math questions? Why and why not? How to evaluate the answers?
This does not mean that tech interviews should be predictable — on the contrary, they should present challenges so that job candidates can really exercise their mind; but they should be predictably challenging — i.e. the job candidate will know that their web development (and not data science) skills are going to be tested. As evidenced by interviewing.io, this lack of consensus leads to unpleasant results:
Interviewee performance from interview to interview varied quite a bit, even for people with a high average performance.
This graph shows that only ~25% of candidates are able to consistently deliver great technical score in their interviews, which really puts everything into perspective. However, the decision whether the candidate made it or failed happens in a vacuum: their past interview performance becomes irrelevant. To remedy this, companies like interviewing.io aim create a universal technical interview platform, enabling recruiters to see a broader picture of their candidates.
One Chance, One Opportunity
Throughout the developer community, technical interviews are often referred to as “games”: sure, they have sets of rules and are generally played in a fair manner, but games are games — which means that you can lose at them. This is quite a depressing thought for developers who spend as much as 6 months preparing for their interviews; eventually, long hours of studying do pay off, but not necessarily at the first interview. After a stressful round of live coding, the candidate may think they totally bombed the interview — only to learn that they actually passed it successfully. Well, they would be probably be overwhelmed with joy and satisfaction… right?
Oddly enough, the reaction is exactly opposite: another study reveals that negative self-evaluation during the interview (even if the candidate actually performed well) results in less desire to work with the company. Increased by impostor syndrome (so prevalent among intellectual professions), this phenomenon affects prospective candidates and costs companies many great professionals.
Making Your Technical Interview Better
Good news is: with certain dedication, you can improve your hiring process. Although ideas like universal tech interview platforms are only glimpses of the near future, you can use a number of practices today to allow for a better hiring tomorrow.
Candidate’s Ability to Learn
With technologies rapidly emerging, evolving, and disappearing into oblivion, a candidate’s ability to acquire new relevant knowledge becomes paramount — and this translates to improving technical interviews: it is important to gauge just how effective your job candidate can learn. Today, programming language A and its related APIs and frameworks may reign supreme, but tomorrow everything can change — and developers all around the world will rush to learn language B. Therefore, you can enhance your hiring strategy via discussing this notion with your interviewee:
- Ask them which technologies they have learned as of late, what the learning process included, and, most importantly, how they applied this new knowledge
- Ask them to model a business concept you give them, trying to follow their logic, problem-solving and learning in a real-world scenario
Naturally, this kind of discussion does not have right or wrong answers; instead, it can help you assess a bit better. Many developers like to highlight that they are lifelong learners, so you can prepare an interesting task for them: note any mistakes the candidate made, then provide them with a laptop and a fixed amount of time to research and correct them. Alternatively, you can ask the interviewee to design a simple algorithm using an esoteric language that they are not familiar with — this task would create an ideal learning environment and test how the candidate can utilize their fundamental computer science knowledge to deal with the unknown.
Tailoring Your Own Questions
- Easy to explain and understand, requiring no special terminology
- Have at least two intuitive solutions that can be written down in less than five minutes
- Do not require specific knowledge of a particular ‘trick’ or language (i.e. the question should not be trivial in Language A and complicated in Language B)
- Hintable: if the interviewee gets stuck, you should be able to lead them towards a possible solution
Curiously enough, one of the most important points is this: make your questions understandable! As evidenced by a study conducted by Pramp, a company that created a platform for mock interviews and coding problems, the mistake of misunderstanding the question is prevalent in 9.11% of all technical interviews. Of course, sometimes the fault is in the candidates too shy or lazy to ask for clarifications, but sometimes the interview question is just too vaguely formulated.
Technical interviews are not the absolute evil — developers and recruiters are often lucky enough to conduct them without a hitch, successfully netting the company a great developer. Still, there are certain aspects that can be improved upon — and the community is working to fix these problems. Love them or hate them, but technical interviews are here to stay, so make sure to stick around and catch our latest blog posts covering interview questions!
Angular framework is a great solution for your next web project. Find out how to conduct a successful technical interview with an Angular>>>
Python developers can contribute a great deal to your project. The tricky thing is finding the best Python developers via well-conducted technical>>>