Programming interviews often times get a bad reputation for being highly stressful and overly complex when they don't need to be. You can find horror story after horror story online about developers being put through the gamut with questions involving golf balls in cars and cryptic acronyms that very few have ever encountered.
Yet, very little has changed over the past decade or so in terms of fixing this. And in fact, some would argue that things have gotten worse. Questions are more cryptic than ever before and interviews can last weeks instead of just a few hours.
Some companies have even been accused of using the interview process in order to get free code written for them. The quality of the code might be questionable, but that's beside the point.
The biggest issue
There's a few issues actually, but let's start with the biggest one that I myself have seen first hand time and time again. And that's the fact that most (from my experience) interviews and interview questions have little to do with the actual job at hand.
For example, in the past I would apply to a job as a C# web developer, only to spend 80% of the time getting questioned about multithreading and multiple inheritance, along with a few other concepts that don't often get implemented in a real-world application.
And how do I know that these questions are irrelevant to the company? Well, because I've worked at several of these companies after making it through their interviews only to discover that they operate much like your typical website without any fancy bells and whistles. There is not multithreading and there's barely even a class hierarchy.
Yet the questions where still there for some reason as a gatekeeper and it didn't seem like anyone at these companies really even noticed that the questions might not make the most sense for the job.
I myself have also been on the interviewer side of the chair and am guilty of asking questions that may or may not have had anything to do with the job. And it was mainly because development interviews typically had to reach a certain time limit and cover a certain volume of questions. They couldn't be too short and they need some form of physical evaluation, like a checklist of questions.
That was more of a HR requirement, as after each interview I would have to submit a feedback form with my thoughts. So I couldn't really just have a casual chat about code and life and culture fit.
So to some extent, I do understand the cause of the problem. But I'm not going to defend it in any way, because I personally never enjoyed performing those kind of interviews and in the end I'm not too sure how valuable they were.
I'll say now though, that this really depends on the particular company and their hiring processes.
Irrelevant coding problems
Whether you're implementing yet another Linked List, or a Binary Search Tree, or the shortest path between two nodes, it's safe to assume that you won't be doing that during your day to day workload. I personally never have and I don't see myself having to at any point in the near future.
You might even get asked to implement some kind of cipher from 500 years ago.
var alphabet = "abcdefghijklmnopqrstuvwxyz";
var newalpha = "";
function shift(n){
for (let i = 0; i < alphabet.length; i++){
let offset = (i + n) % alphabet.length;
newalpha += alphabet[offset];
}
}
function encode(message){
let result = "";
message = message.toLowerCase();
for (let i = 0; i < message.length; i++){
let index = alphabet.indexOf(message[i]);
result += newalpha[index];
}
return result;
}
FYI, never use an archaic cipher in a real-world application.
You might not technically get asked to implement an ancient algorithm, but there's a chance that you will be asked to reverse strings, find values in a set or perform other types of algorithmic problems. Fair enough, but in my personal day to day coding life, the following seems more accurate:
- Design database schema
- Implement RESTful API's
- Create designs based on specifications
- Write JavaScript code to bind data to the page
Yet, in order to land the job, you'll have to ignore your actual skillset in whatever framework you're an ace in, and you'll need to brush up on your algorithms. And if you're a more senior developer who has spent a fair number of years out in the field working on actual software applications, then you might have a more difficult time with this task. And I am included in that list.
I can still remember the day that I was asked to write a function that would detect whether a Linked List was circular in nature. And after finally having figured out a viable solution, since I hadn't touched a Linked List in years, I was asked to do it again but in a "slightly different way".
Essentially, the person interviewing me already had a solution in mind and written down in front of them. And they weren't going to consider my answer valid until whatever I wrote matched their own code.
Did I end up getting it? Not at all. And that was the only real question asked during the coding phase.
In contrast though, I was once tasked with coding out a functional contact form on a webpage from conception to design with little to no guidance. Essentially, the goal was to see how I would structure out the application, how I would write queries, bind data to a form and perform a postback operation.
I personally thoroughly enjoyed that interview because it allowed me to focus on the thing that I was already doing on a daily basis. And that's building websites.
And I'm not the only one of course. Many developers spend an enormous amount of time in practicing overly complex and mathematical challenges, in lieu of actually working on their practical coding skills.
Not testing for much
With many interviews today testing theory, keywords and logic based puzzle questions and not much else, it's becoming a challenge to identify ideal candidates for a particular job. And as someone who spends some portion of the year hiring to fill tech positions, I can say that this definitely has impacted me as well.
More recently as I was looking to fill a junior position as a QA engineer, I had to prepare questions for a 30 minute interview. The number of candidates to wade through was surprisingly high and I had to narrow down the list to around 12 candidates or so.
Pretty much everyone that joined this interview was prepared in terms of knowing textbook definitions for various keywords related to QA, such as regression testing and unit testing. But when it came to the more practical side of things, pretty much every single candidate failed to understand what a basic regression test actually consisted of.
Most had never heard of the development console in the browser, which limited their ability to test different environments, and equally most had no real method of tracking down and reporting issues aside from stating the issues out loud.
The theory was there but anything else simply was not. But imagine if I were to remove the practical portion of the interview, in favor of a more puzzle styled questions. The number of qualified candidates would shoot through the roof. And I wouldn't even know there was an issue until after they were hired on and had their first big task.
And that can be a huge detriment to the company and to the person themselves.
Why it won't get fixed soon
One of the reasons why interview questions are often times irrelevant or seemingly over-complex is because large companies interview hundreds of candidates per month and they need a way to standardize the process.
This is why you often research certain companies and find that they are asking similar questions as many others. Most companies just don't have the time to prepare a specialized interview for your particular skills only.
Smaller tech companies however do have this time, and you often will find that they stray away from theory and riddles and focus more on practicality.
But at the end of the day, the larger tech firms account for a huge portion of the available development work out in the world today, and so many of the standards essentially get set by them.
So until something better comes along, for now, we'll have to stay busy with bubble sorts and big O notation questions in order to land our next big job.