With the abrupt changes to how we live and work, many individuals are unexpectedly finding themselves in a volatile job market. A job-search is always hard. However, for engineers in particular there is a unique barrier that leads to frustration and anxiety — the technical interview.
In traditional technical interviews, candidates are often asked to solve problems covering theoretical concepts taught in college-level computer science classrooms e.g., sorting algorithms, search trees, etc. While great engineers know how to use these tools, most never directly implement them in their daily work, and certainly not from memory. Every modern coding language abstracts them away to allow engineers to focus on doing their job — building great products. As a result, preparing for these interviews can require months of studying — months that many candidates do not have, especially now.
So, why does the industry continue using theoretical algorithms interviews?
While building Byteboard, we've heard many arguments defending the use of these traditional interviews. They fall into three primary categories:
- Everyone does it, i.e., "It's the status quo!"
- It's convenient
- Candidates should be prepared for theoretical questions
It's the status quo!
Theoretical algorithms questions are the standard across the industry. Most engineers experience them as candidates and then in turn use them as interviewers. There are now extensive interview guides on all the algorithms and data structures you should master for technical interviews, as well as a plethora of sites to practice on.
As a result, the status quo has become one that privileges those with the time, resources, and insider knowledge on how to prepare. It would be one thing if these interviews were otherwise effective but research shows that traditional technical interview performance is pretty arbitrary and wildly inconsistent [1]. Additionally, the interview itself is so anxiety-inducing that we've talked to several engineers who do everything they can to avoid coding interviews altogether, staying at jobs longer than they otherwise would have.
We love a good quote, and we love it even more when the words were spoken by an incredible (dare we say bad-ass?) female computer scientist:
"The most damaging phrase in the language is ‘We've always done it this way." Grace Hopper
It's convenient
There is no shortage of example interview questions available online. Many companies adopt a model where each interviewer finds or creates an interview question in this format, which seems to scale.
But, let's be real — being a great engineer does not always translate to being a great interviewer. And relatedly, the sheer availability of algorithms questions does not make the average question a good one. This is especially true when questions are unvetted or don't have structured rubrics to ensure consistent evaluation. At its best, this lack of quality control results in an inability to properly assess candidates for their skills; at its worst, it enables biased evaluation.
Candidates should be prepared for theoretical questions
Algorithms and data structures are important. And when you had to spend three months preparing to get your job, why shouldn't the next candidate? After all, spending time preparing demonstrates character. Right?
Sounds oddly reminiscent of college hazing practices, wouldn't you say?
Our task as interviewers is to assess if a candidate can do the job. And it's true — knowledge of algorithms and data structures IS important. But only to the extent that it is valuable in your daily work. The fact that many actively working engineers feel they need to spend over 100 hours studying for interviews indicates that we are going too far [2].
The reality is that we've historically used this ability to prepare and do well on coding interview as a proxy for real engineering skills, but that does not make it a good proxy. In fact, it is one with fundamental inequities. Some candidates don't have time to prepare; others, especially those that are new to the industry, don't realize they need to. Some candidates assume their ability will be enough, while others study at universities that offer courses on "Mastering the Software Engineering Interview." Preparedness only tells us one thing — the candidate knew what was going to be on the test and had time to study.
Frustration with societal acceptance of the status quo has been the catalyst for nearly every major movement in history. Our frustration with technical interviews is why we started Byteboard. We wanted to create a technical interview that assesses real engineering skills, like writing clean code, trade-off analysis, and written communication. We also wanted to create an experience that limits candidate anxiety and evaluates fairly. An interview that (you guessed it!) does not require engineers to spend months preparing to do well.
It's time for us to stop saying, ‘We've always done it this way.' Our world, our lives, and our work are changing, so should technical interviews.
[1] https://blog.interviewing.io/technical-interview-performance-is-kind-of-arbitrary-heres-the-data/
[2] https://blog.interviewing.io/the-eng-hiring-bar-what-the-hell-is-it/