In this blog entry, I wanted to talk about why I think the technical interview process is broken and I want to give my thoughts on how the industry can improve the technical interview process.
Background
Throughout my career I have participated in a number of interviews throughout the years. One thing I can tell you with 100% certainty is that I really hate interviewing and I believe that the process in which technical resources are evaluated is broken and as a result, organizations are missing out on good talent. I’ll first talk about some of the issues I have with the current technical interview process and then provide some ideas on how the industry can improve the technical interview process.
One Size Fits All!
One of my biggest issues with the technical interview process is that many companies have a “one size fits all” interview process. Whether you are interviewing for a Jr. Developer position or as an Architect, some interviewers will ask each candidate the same set up questions. I have had countless interviews, many of them recently where I was applying for a Lead or Architect role but was asked questions that one would ask a recent college graduate. The problem with this approach is that it reduces the process to the lowest common denominator and it is literally a waste of time for both the interviewer and an experienced professional to take part in these types of interviews.
One of the reasons why I believe asking experienced professionals very generic and basic questions is a waste is because many experienced professionals have moved on from basic College textbook knowledge and literally have not thought about those subjects for years because many times, the things learned in College are not applicable to what you do in the real world. In one interview, I was asked to give the exact definition of Boyce-Codd Normal Form, which is a term I have not heard since my Database Class in College.
Unrealstic Code Challenges
Another aspect of the technical interview process that I think is broken is the so called “Code Challenge”. In my blog The Programming Interview, I talked about Code Challenges and gave some advice on what they consist of and how to administer them.
Many of the Code Challenges that I have come across are completely irrelevant to the type of job a technical resource will be performing. Candidates are asked to solve arcane algorithms, program in Notepad-like editors and they are timed. None of the aforementioned is something a candidate will likely be asked to do on the job and thus is not a real predictor of whether a candidate will be good at their job.
In one interview, I was asked to navigate to a link that had a Notepad-like editor and program in C# in front of 5 people. The Code Challenges I was asked to solve were not real world problems, I would never use an editor with no Intellisense and I have never been in a work environment where 5 people stood over my shoulder and watched me do my job.
Being Asked Questions the Interviewer Doesn’t know!
Another issue I have personally witnessed is candidates being asked questions that the interviewer themselves do not know. This type of behavior is typical of the “Stump the Chump” interview and a situation where the interviewer just googled what are some good interview questions and used that as a method to interview each candidate, again, irrespective of the candidate’s experience level.
On one recent interview, I was asked a question, I was able to name 3 out of 4 of the items, eventually told the interviewer I couldn’t remember the 4th item and the interviewer’s exact response was “Yeah, I can’t remember the 4th item off the top of my head either”.
Too Little Focus on the Candidate’s Background!
I believe that another problem with most technical interview processes is that many do not focus enough on the candidate’s background. In many of the interviews that I have had, I was not asked much about the projects I have worked on and the technologies used. Typically, the interviewer will ask you to give a brief overview of you background but from my experience, the actual technical questions will come from a pre-made list. The problem with this approach is that some of the pre-made technical questions may not be relevant to the candidate’s background and the interviewer is not able to dig deeper into the actual technologies on the candidate’s resume, to get a feel for their level of expertise.
Also, the Software Developer position is one of the hardest industries to interview for a position because the scope of questions in which the interviewer can ask is so huge. You could be asked very deep questions about the front-end, the back-end, databases, architecture, different languages and DevOps. This is why I believe it is crucial to limit the scope of the interview to the candidate’s background and the technologies they will be working on at your company.
Improving the Technical Interview Process!
Next, although no interview process is perfect, I will discuss some ways that the technical interview process can be improved.
First: All of my technical questions would be based on what is on the candidate’s resume and the technology we use/going to use at our company, not from a pre-made list of technical questions. If I am not competent in the technologies on the candidate’s resume then I will find another individual in the company who is strong in those technologies. Conducting interviews in this manner allows you to customize the interview based on experience and the position the candidate is seeking.
Second: All Coding Challenges will be realistic, pertinent to the job and the candidate will be given the option to do the Coding Challenge in the comfort of their home. I would not be worried about cheaters because a good Code Review Interview and an interview tailored to the candidate can weed out those who chose to cheat. Allowing the individual to do the coding challenge in the comfort of their home allows them to use their own equipment, their own tools, reduces nervousness and present a more realistic environment in which they will be working.
Third: If I wanted to have a candidate perform an in-person Coding Challenge on top of a general Coding Challenge they have already done in the comfort of their home, I am going to prefer Whiteboarding over asking them to pump out actual code. Whiteboarding a design or Coding Challenge allows me to see how the candidate thinks and how they go about solving problem without having to worry about all the lower details such as syntax and whether the final solution will compile.