Why Programming Job Interview Questions Are Challenging?
I have a strong dislike for programming job interview questions. They always seem so difficult, and I often wonder why that is the case.
If you have ever used platforms like HackerRank or read books on coding interview questions, you’ll likely agree with me. The coding interview industry has grown enormously and preparation for these interviews has become a whole new field.
Personally, I despise them. Not everyone on the internet shares my sentiment though. It seems that many individuals want to continue this “tradition.”
A few years ago, I decided to switch from contracting/freelancing to being a full-time employee, so I went through the hiring process with several different companies.
About half of the companies I applied to had an initial screening process which involved a practical “take-home” project. None of them asked me to implement FizzBuzz or any other algorithms that are often deemed as “required knowledge.”
Sometimes, we might mistakenly believe that every hiring process is like the one experienced at Google. I’ve read stories of people spending up to a year preparing specifically for the Google interview, only to be rejected when they finally applied. It’s quite disheartening.
The truth is, there are numerous small and medium-sized companies that follow a different hiring approach. They do not conduct rigorous technical interviews on topics like algorithms and data structures, nor do they expect candidates to write code on a whiteboard without access to Google or Stack Overflow.
Now, I am not saying that it’s not beneficial to have a deep understanding of these topics. I believe that it is essential. However, the reality is that when asked to solve algorithmic problems during an interview, we often end up explaining what we remember from a previously memorized problem. Fresh graduates might recall it well, but individuals with several years of work experience might struggle to remember.
Implementing FizzBuzz might be a more reasonable approach. It is not typically taught in school, the problem can be explained within three minutes, and it allows for a discussion on logical reasoning.
However, if I were to organize the hiring process for my own company, I would never subject interviewees to implementing FizzBuzz on a whiteboard. Why? Firstly, it is completely useless. The truth is that you will never have to implement FizzBuzz in the real world.
Secondly, it places unnecessary stress on the applicant. Many people underperform in such high-pressure situations, including myself. I would estimate that under those conditions, I am only able to showcase about 10% of my true value simply because I do not function well in such an unnatural environment.
DHH (David Heinemeier Hansson), the creator of the popular Ruby on Rails framework, once tweeted: “I would fail to write bubble sort on a whiteboard.” And I agree.
Administering a technical interview on a traditional whiteboard is awful and, at best, a means to test the applicant’s ability to handle stress. However, this is quite different from testing their skills to provide value to the company, such as their programming abilities.
The reality is that none of the problems one solves in a typical whiteboard interview correlate with the actual job of a programmer. I cannot recall the last time I had to spend time deciding which algorithms to use, let alone implement a completely new algorithm. So, why are people continuously asked about these things?
Thankfully, it appears that even big companies are beginning to transition towards more practical interview processes. Here’s a tweet that highlights this positive change:
“We’ve updated the wording we send to the Front End Engineer candidates to better reflect the Facebook interview process for that role. I hope this helps folks prepare for their interviews!” - Dan Abramov
Practical knowledge is what we need. Test us on this.
One cool question I recall from an interview was when they asked me to describe what happens when you do a Google search. It was an open-ended question that initiated a conversation on network protocols and the finer details of the process. It was truly an intelligent question.
Moreover, there was no whiteboard involved because the interview was a remote Zoom call.
In another interview, I was given a coding challenge that I implemented using React offline. I had seven days to complete it (though it only took me three hours of actual coding). The subsequent stages of the hiring process were based on the work I did for this challenge.
So, in answering the question of why programming job interview questions are so difficult, I would argue that the problem resides in the broken hiring processes of many companies. In such situations, it is worth considering whether you truly want to work for them.
Wouldn’t it be better to bypass the interview process entirely? The ideal situation would be for a company to approach you with a job offer. There are various ways to achieve this, with networking being one of the more traditional methods. You can establish connections at conferences, on Twitter, or on GitHub. Once you are known and valued by employees of a company, you can more easily be considered for future positions.
This is, of course, just my humble opinion.
tags: [“interview questions”, “programming jobs”, “technical interviews”, “hiring process”, “coding”, “algorithms”, “coding interview”, “practical knowledge”, “whiteboard interview”]