Tech interviews are broken.
Most of us in the tech industry might have heard the phrase “Tech interviews are broken”. What does it actually mean? Is it really broken? How is it broken? and What can be done to fix it? These are some of the questions that I hope to answer in this blog post.
If you are involved in technical hiring/recruitment in your company, this post might contain something for you.
Some background
I have been working in the tech industry for close to 6 years now. Throughout this time I have worked full-time in 4 companies, freelanced for a couple, and been involved in tech interviews on both the interviewer and the interviewee side, totaling close to 40-50 interviews. I have given technical interviews for international companies, and have taken interviews of interviewees from different countries as well. After being involved in all these interviews, I too stand by the statement “Tech interviews are broken”.
Why?
After talking with some colleagues and engineers involved in these interviews, following things stood out to me about tech interviews:
1. Questions/tasks unrelated to the actual job
Most of what is asked within the interview does not have any direct relation with the job that is being interviewed for. I have seen people ask and being asked to do system design for a Software Engineer level position(where system design is not a requirement for the role), questions about the latest JS framework features like when the codebase they will be working on is more than a couple of major versions old, questions about microservices and their challenges when the job is primarily concerned with a monolith service. This shows a divide between the questions asked, the topics discussed and the actually job.
2. Proper expectations not set
Setting proper expectations for the interviewee should be the primary goal of the interviewer and/or the recruiter. I have been in interviews where I did not have any clue as to what type of interview it would be. Would it be an interview where I had to whiteboard a solution to a question? Would it involve systems design? Was it just an interview related to the technical requirements mentioned in the job description? or was it a mixture of two or more? These were the questions that I would ask the recruiter when the interview was scheduled. More often than not, I would not get a straightforward answer. I have also played the part of the interviewer in interviews where after the interview started, the expectation from the interviewee was totally different than what the interview was supposed to be.
3. One-sided Q&A
Often interviews are the interviewer asking the questions and the interviewee answering/trying to answer them. The inherent power dynamics in this setting is something which can affect the interviewee. It isn’t a suitable environment where the interviewee can best show their abilities and skills so, n addition to other responsibilities for the interviewer, easing the interviewee into this dynamic should also be one of them. I have forgotten things that I knew and fumbled quite a bit with answers to simple questions when being asked rapid-fire questions while being nervous.
What to do then?
What can be done to tackle these issues in your organization? Gradual implementation of the suggestions that will follow will undoubtedly improve the interview process in your organization.
1. Set baseline expectations of what the interview will entail
Start by setting expectations for the interview by the interviewer or recruiter even before the interview process begins. A good example of this would be setting the expectations for the interviewee regarding the type of interview it is; If it will be a full-on coding challenge, generic questions about a certain technology, system design-related interview, database-related questions, etc.
2. Ease the candidate into the interview
Always start by introducing yourself and getting to know the interviewee first. Getting to know each other and talking for a while will increase familiarity and comfort. Then, it might be a good idea to dive into the background or previous experiences to know more about the interviewee and what type of work they have experience with. Continue with questions related to their previous work and then tie those up with questions related to the current job being interviewed for. (If possible) Another way to increase comfort in the interview is by asking at the beginning of the interview which language they would prefer the interview be in. E.g. I always ask if the interviewee would prefer the interview to be in Nepali, English, or a mix of both. You can also ask for their preference if applicable.
3. Avoid asking definitions and questions from a list
Asking for answers from a standard list of questions would just be wasting both the interviewer’s and interviewee’s time. Doing this doesn’t take into account things like their past work experience or their creativity in solving problems. Questions that relate to the job, as well as their past work, will shine a light on how much contribution they made and the knowledge they gained from it. Hypotheticals like additional constraints to a decision that they made previously with different sets of constraints can test their understanding, adaptability and creativity.
5. Provide guidance when necessary
As I have mentioned before, an interview is not supposed to be a Q&A session. I have found interviews where the interviewer and the interviewee collaboratively reach a solution to be useful for gauging the capability of a person. The level of guidance required for the candidate to reach a satisfactory answer can be a major part of the rubric for scoring the interview.
6. Make it a learning experience
Any interview even when the candidate is out of their depth or is not suitable for the job can be useful for both the parties involved if they learn something out of it. Learning from the interview is not just something for the interviewee but also for the interviewer. I have at many times learned new concepts and technologies while conducting interviews because the interviewee had worked on a technology I haven’t worked on before.
Final words
Even if you cannot implement all the above suggestions when you conduct interviews, one thing I would greatly appreciate if everyone tried to do is: Make interviews suck less. Our jobs are stressful as they are the least we can do is make interviews suck less for all the people involved.
Some great resources for better tech interviews:
This Interview path for T3 tools
Mock interview by freeCodeCamp