Technical interview requirements are not surprising to software developers. These interviews are used to assess an individual’s technical skills and knowledge for a given role. It commonly consists of coding tests and whiteboarding specific to algorithms or data structures, which requires intense prep work and sometimes even post-interview homework. Many developers dread this rigorous process, so how did this interview process even come to be?
History of Tech Interviews, Bits & Pieces 🧩
The history of technical interviews was not an easy one to uncover. However, we found bits and pieces of information from Forbes, CoderPad, and Medium articles. According to these sources, in the 1970s, computers were so expensive that developers couldn’t afford to own one. Though desktops became affordable in the 1990s, it wasn’t reasonable to expect developers to lug their systems to technical interviews. As a result, developers were accustomed to writing code using paper and pen. Whiteboards existed at this time; however, this practice grew to be widely accepted when the demand for software development rose and when dry-erase markers were invented for the ease of wiping and correcting mistakes. Transitioning from paper and pen to whiteboard and marker made writing and solving problems far easier.
Now that we learned a bit about whiteboarding, the real question is, how did these coding tests become the industry standard to assess developers? According to Wikipedia’s page on coding interviews, tech interviews emerged from Microsoft’s “technical problem-based job interview,” later adapted by companies like Amazon, Facebook and Google. Ok, but what was so special about Microsoft’s interview? Bill Gates’ love for puzzles led him to develop an interview practice that tested an individual’s ability to code, design, and solve problems, which was a non-existent process at the time, thanks Bill!?
Decades have passed, yet many companies still require coding and whiteboarding components in interviews. Why? A potential reason could be that not everyone is ready to challenge the traditional processes because of their “it’s always been that way” mindset. We don’t have to stick to conventional ways of doing things just because it generates the expected output. If that were the case, technological advancements would not be needed.
Why Developers Hate Tech Interviews ❌
Requires Arduous Preparation 📚
Prepping for technical interviews well before the interview itself is no easy feat. The level of preparation required varies from person to person based on their level of experience and willingness to allocate time to prep. Generally, it may take between one to three months to fully prepare. It’s also important to remember that not all companies conduct technical interviews the same way. It’s meant to be unreasonably onerous and may take a few tries to complete successfully.
Time-Consuming Process ⏳
In many instances, candidates have to dedicate several weeks or even months to complete an interviewing process because there are multiple rounds of technical tests. In addition, candidates may even be required to complete specific projects with an unclear scope of work to prove they’re worthy for the role. Imagine facing this situation when you know you have what it takes but constantly have to prove yourself when you decide to switch companies and positions. Even worse, imagine putting in so much effort and hard work to be denied the opportunity. Pretty frustrating, right?
Stress-Inducing Environment 😰
As a software developer, chances are you aren’t going to be watched closely as you write code in your day-to-day work. So what is the need to have candidates perform coding tests and challenges on the spot with an interviewer watching their every move? Many candidates may not be able to showcase their authentic capabilities in a pressurizing setting, leaving room for incorrect and biased assumptions.
Irrelevant to Actual Role 🙅
Believe it or not but we’ve heard this concern from numerous software developers. The amount of time and intense effort that goes into technical interview preparation and performance are rarely reflected in the actual position a candidate is interviewing for. Developers are heavily tested on problems they’d likely never come across once they’re hired. Think of it as training to ski on the mountain top, but you’re taken to the bunny hill instead. Shouldn’t these assessments reflect what you’ll actually be doing in the role?
Research Findings Confirm Tech Interview Flaws 🔍
Anecdotally, we know how painful technical interviews are and there isn’t extensive research to support our experiences. However, some studies point out the flaws and gaps, suggesting that there is much room to improve how technical interviews are conducted. Let’s look at some of these research studies and their key findings.
Testing Performance Anxiety Over Skills
Let’s be honest, interviews can be anxiety-provoking. We often feel caught between determining our fit for the role and the pressure to perform well to land the job. But what are hiring managers really assessing in interviews, the candidate’s technical abilities or performance anxiety? Feeling anxious or overwhelmed when performing work under a watchful eye is natural and commonly experienced by many. Using this measure to judge a candidate’s capability is unfair as they may be high performers if given the freedom and space to work privately.
In 2020, North Carolina State University and Microsoft conducted research revealing the drawbacks of technical interviews.
Notably, candidates who participated in traditional technical interviews with the interviewer watching them experienced significantly higher stress, higher cognitive load (usage of working memory), and lower scores than those who participated in private interviews with no observation.
In fact, the procedure of conducting technical interviews was very similar to the Trier Social Stress Test, which is a psychological method used to induce stress. Consequently, these whiteboarding and coding tests may not be deemed appropriate measures of a candidate’s technical competency.
Interview Performance ≠ Job Performance
A candidate’s performance in an interview may not always be indicative of how they perform in a given role. There are several influential factors in an interview process that may or may not work in favour of the candidate. Some candidates have a strong interview presence and may be average performers, while others may have a weak interview presence and may be high performers. It varies from candidate to candidate, which an interview process doesn’t fully consider when determining candidate fit for a role.
Based on a study conducted by interviewing.io, a candidate’s performance in technical interviews is not correlated to their job performance. The results revealed how misleading this assessment actually is.
Only 25% of candidates performed consistently in interviews while developers who were considered strong candidates performed poorly 22% of the time.
From the candidates’ perspective, findings indicate that candidates cannot gauge their interview performance. They tend to underestimate their performance, pointing to imposter syndrome. As a result, candidates were less interested in companies they interviewed with simply because they thought they performed poorly when they actually performed well.
What does all this mean?
- Technical interviews do not accurately measure or represent the performance of all developers if only one-fourth of them perform consistently.
- Many talented developers may slip through the cracks due to poor interview performances, which may be attributed to several situational or behavioural factors.
- These interviews need significant improvements to create a positive candidate experience that fairly evaluates a candidate’s capabilities, all while avoiding snapshot judgements. For instance, using interview time appropriately to let candidates share their top strengths and providing constructive feedback in that given moment goes a long way than leaving candidates deliberately uninformed.
Tech Interview Biases
All interviewing processes are subject to conscious and unconscious biases, and technical interviews are no different. Many interview outcomes depend on an interviewer’s impressions in the first ten seconds of meeting the candidate. Previously, we learned that technical interviews could quickly push aside strong candidates due to poor interview performances. Unfortunately, that’s not the only bias, according to North Carolina State University and Microsoft’s research.
It appears that whiteboard technical interviews favour men over women and preferred candidates are given easier questions.
Moreover, the interview environment played a significant role in women candidates’ performance. Results revealed that women candidates could not solve coding problems in a public setting. However, when asked to solve the problems in a private setting, all women completed it correctly and successfully. Isn’t it interesting that one’s performance can go from poor to strong based on the interviewing environment alone? But women developers who were considered poor performers when they may have been strong performers led to serious career decisions.
Specifically, interviewing.io’s data suggests that after a poor interview performance, women are seven times more likely than men to discontinue their software development careers. This stat highlights how broken technical interviews really are.
The concerning point is that candidates who are great at interviewing and accustomed to the technical interview process are at an unfair advantage. Acing a technical interview is challenging, but if candidates know what they’re getting into, they may be well equipped to tackle it.
If you know how to play the game, you’re more likely to win than someone who has little to no idea about the game. This significantly hits the underrepresented and marginalized groups, as they may not have the resources, network, or special support to navigate these processes.
If you’re looking to prepare for technical interviews, check out our comprehensive guide and the tips we got from Twitter’s Site Reliability Engineer, Sean Prashad.
As discussed earlier, interview performance is not highly indicative of job performance, so this evaluation method unarguably creates a bias, allowing great interview performers through subsequent stages of an interview process while pushing out the rest without giving them a fair chance. It’s not always easy to recognize when judgements and biases kick in, so it’s crucial to focus on what candidates can bring to the table rather than on unnecessary superficialities.
Technical interviews may be the preferred method to evaluate developers, but it’s time this perception changes because its flaws are closing doors on high performers misconceived as poor performers, women, and underrepresented and marginalized groups. Technical interviews should be continually refined, updated or even replaced so it opens doors to all deserving talents, irrespective of social categories.
At Commit, We Practice What We Preach 💪
At Commit, we believe that traditional technical interviews fail to capture and assess a developer’s full abilities. Our technical assessment is an open-ended, transparent conversation to have developers elaborately describe their experiences. This conversational approach creates a stress-free, comfortable environment and requires no preparation, enabling a positive candidate experience.
As we’ve discussed, traditional technical interviews expect developers to complete coding and whiteboard exercises before, during or after an interview – not to mention that all this work to demonstrate skill proficiency may not be required for the day-to-day work of the specified role. The lack of clarity about what skills a particular position may or may not need is what leads to multiple rounds of technical assessments, making it a frustrating experience for developers. That’s why at Commit, we tailor opportunities to our developers, allowing us to focus on the developer’s top strengths. This lets the developers showcase their best skills instead of checking boxes on a random list of technical skills.
The outcome of this conversation provides us with a lot of information about the developer’s thought process, depth of knowledge and understanding, ability to solve problems, and seniority level with the tools and systems they describe to us. It may not provide us with enough insight into how they write code. However, in our assessors’ experience, if a developer can effectively communicate the technicalities of their work at the level we expect, they are likely very capable of writing code at the level we require. Even if our developers feel they are slightly stronger or weaker in one area than another, as a community, we help them accelerate their strengths and provide mentorship and support so they can develop skills they wish to learn or improve. It’s not always about hiring someone who knows it all; it’s about identifying talented individuals who are passionate about building and cultivating their craft.
As an organization built for developers by developers, we know the frustrations and partialities developers face in the name of technical interviews. With this in mind, our interview process is structured to make career transitions smooth for developers and to highlight that technical vetting is possible without a series of rigorous coding tests.
This experience is a top priority for us, so we also ask our startup partners not to include technical tests in their interviews to create a worry-free experience for our developers. Since our engineering team has years of startup and software development experience, we’re beyond confident in their ability to assess the candidates’ soft and hard skills.
To make developers’ career transitions easier, we’ve implemented the changes we wished to see in technical assessments. When will you start challenging the conventional ways of conducting technical interviews?