Over the years I’ve been hiring many talented people. I started out with the old way when I would select a bunch of applicants based on their CVs and ask them to come to the office. During the interview, they would solve coding assignments, and we would chat to get a total overview of the person. It worked, and we were able to land some great people, but it was all very local and very time-consuming. Since then, a lot has changed. The companies I’ve worked for have moved to from local talent to global talent and started to hire people all over the world. With this decision, everything changed. No more on-site interviews, no more whiteboard code assignments. With the increased talent pool, we also needed to scale the process and save our time. With all these interviews and experiences, I have found many ways how candidates sabotage their chances of getting the position. Here are the 12 things to do if you really want to sabotage your interview. If you want to avoid these simple mistakes, get your notebook and take notes.
Don’t test your setup (connection, cam, mic)
No matter how good, charming, or extraordinary you are, if you have no reliable connection and there is no way to get this information through, you will not get the job. If I see you having a terrible connection during the first impression, then why should I expect the situation to be better going forward. Sure, there are special circumstances as always, but generally it is just lack of preparation or motivation.
Don’t check what’s visible in your camera background
Your presence matters, and bad presence is distracting and worrying. Nowadays, all the video call tools have solutions to blur or replace your background, so there is really no reason to have bad background. Years ago, when this feature was not present, I had some interesting calls where people would have piles of dirty dishes and drying laundry in the background. Although it does not affect the person's skills, it adds to the impression the person makes. There is a saying: “The way you do something is the day you do everything” and in many cases it is accurate.
Don’t prepare standard questions
There are a few standard questions that are probably asked in every interview and when I see someone starting to figure out their answer it creates a lot of concerns. Mostly that the person does not have enough motivation or does not care enough to take time to prepare. Some examples are: “Why did you apply for the job?”, “Tell me about yourself”.
Don’t be humble (you are awesome and if they don’t see it screw them, their loss)
I have seen very interesting people who tell me that they feel the job is so easy that they will do it on the side of their main project. The other interesting case is when the person actually asked for a raise during the interview, indicating that his skills and experience is so strong that he will be multiple times better than everybody else in the team. In this case, it is strange to think you are a prodigy without knowing the talent that is already in the company. Basically discrediting the company and job by saying you see no challenge or everything is simple, is a bad tone to start with.
Don’t ask questions
The awkward silence when being asked to throw some questions in the air is the death of the interview. What interviewers look for in this situation is to see if the person has imagined themselves in the position. They should ask about the way of working, how many meetings, how are tasks divided, how are we keeping people happy, are there some educational programmes, how is the growth of employees handled. Any one of these topics would be a good sign of really being interested in the company and the position.
Don’t talk when coding
When getting a coding assignment, the real value is the approach you take, not the outcome. The interviewer wants to see how you think, where you start from, and how you connect different parts of the problem. Usually you are asked to be vocal about your ideas and approaches, so keep it in mind. If you are silent and just create code, it is bad in many ways. No-one will understand the idea you had, and no-one can correct the direction if you are going the wrong way. As with every part of the interview, you want to bring in the people on the call to the journey, so they are with you and thinking along. Having more visibility and engagement will actually make everybody kind of root for you and even give you needed hints or pointers.
Don’t follow instructions
Throughout the interview, you are given instructions and scenarios to follow. One of the important part of your job here is to make sure you follow them. It is always OK to verify that you understood something correctly or ask the instructions to be repeated, but it’s not OK to ignore the guidelines given and work on your own agenda. A bad example is a case where I asked the candidate to finish working on a coding problem, and they told me that no, they want to formalize it, and they will finish it up. This wasn’t putting a dot to the end, it was 10 minutes of effort to make the code work. Sadly, in the end, the code did still not work.
Don’t agree with the interviewer and stick to your statement
If you are right, you are right, right?
Coding interviews are always about much more than just being able to code and deliver solutions. These calls are also about understanding the way the person works and what it would be like to collaborate with this person. If for some reason there is no alignment or good feeling of collaboration, then no matter how good the person is, they will not get hired. If during the interview the interviewer will make a statement you don’t agree, it is OK to challenge it, but not OK to start a debate about the correct and incorrect answer. When a person is OK to escalate an argument when they are meeting the person the first time, they are probably going to have a lot more arguments and collisions once they are more comfortable.
Don’t research anything about the position or company
I can code, the job is about code, what’s there to know?
When a person applies for a position in a company, I would expect them to have a good reasoning why this company and this position is the one that they chose. I would expect them at least to have used the products of the company or have gone to the website and see what the company is all about. Usually this interest should come out in the section where the candidate should ask questions from the interviewer.
Don’t be honest
Lie that you have experience with everything. No-one will know, right?
Everything will come out eventually. There is no reason to come up with elaborated lies about your skills and experiences. If you are applying to a position that is outside your skill set, then it will come out. The expectations will not change and to be able to meet them you will be either taking on a crazy amount of stress or you will just fail hard and leave the company anyway. Be aware that for every lie you have in your resume, the interviewer will dive in and will understand what’s real and what’s made up.
Be needy
If you know you are good, then ask how good you were, and surely they will validate.
The code interview is not the place of asking validation. This is a clear sign of lack of confidence in yourself and in your skills. And honestly you will not get any valuable insights here as mostly interviewers will not share the real opinion, but just that it was OK.
Send follow-ups with more value
If needed, I can do this, this and this to get the position. This shows persistence and will definitely make them change their mind
If the decision is made and not in your favour, then it will not be reconsidered. That is a fact. Bombarding the recruiter with question, and additional info will not get you anywhere. It is OK to ask for feedback and clarification of the reasoning, but mostly you will not get an answer, as it is not usually something simple but a combination of different things that made the scale be against you.
Interviews are hard enough, please don’t make it even more difficult on yourselves. Good luck getting that next position!