Mistakes Engineers Make at Interview Stage by Hamza Ouaghad
So you have a confirmed interview lined up for an engineering role and you’re looking for some advice – look no further!
Hamza Ouaghad (Software Engineer at expertlead) has interviewed over 150 engineers from all different levels. In this article, Hamza gives his advice to ace your next engineering interview.
All of the interviews I've conducted were technical in nature, so some candidates thought that regardless of how you communicate, it's all about skill, which is quite mistaken. What I want to say by that is that the most important key during an interview is communication, and almost all of the mistakes that are made during the interview process, are communication mistakes, not entirely technical mistakes.
Generally, candidates that -say- faced an ambiguous question or felt uncomfortable under the stress of the interview, and have communicated that clearly to the interviewer, were also the candidates that did well, since they could unblock themselves and also attain a higher level of clarity through their communication skills and at the end ace the interview.
On the other hand, candidates that were skilled but did nothing except code, were the candidates that performed poorly overall, since their work comes of "out of tune" or "misses the point" just because they have not communicated clearly when they felt uncomfortable and decided to swallow it instead of questioning again or request a timeout until they can clearly articulate their thought and communicate it.
So that's the first mistake, to not communicate when you are feeling under stress or facing a roadblock. It's also a part of the interview that you raise a flag when blocked or faced ambiguities, and not keep silent and try to figure it out yourself.
Another deadly mistake is when a candidate gives the wrong answer and insists on it. In an attempt to help them, the interviewer would throw a tip or a hint to make them realize it's the wrong answer, just to invite them to rethink again, but instead, the candidate misses the point and insists on their wrong answer, which demonstrates not only lack of knowledge but also the inability to empathise and communicate properly.
The candidates that do well generally are also highly empathic, as they can tell when they are being asked a direct question, or a question that has more than one dimension. So again, communication is key, empathy is the lubrication.
So if communication suffers, and the interviewee leaves the interview feeling unclear, ambiguous and without a clue or idea about what the interviewer was looking to dig out of him, then it's quite a good sign you did not do well in an interview. On other hand, if you leave an interview with a clear idea of what the interviewer was looking for, then it's a good sign you did well or could at least communicate very clearly.
So on those terms, if you want to ace an interview, be there first as a human, realise what the other human wants to get out of you, and then try to best deliver it clearly and precisely.
If there are any tips that I'd want to give software engineers to help them ace their interviews, I would invite them to try to do a lot of pair codings or try to code something while explaining it live to someone else. This way, you can develop what I call "link-points" in the conversation, and those are the parts in which your communication is understandable at both levels technical and non-technical.
An example of this can be found in tutorials in which the speaker is coding but at the same time giving a banal lively example of what they are doing in code. Say, "You can think of this function as a screwdriver and you are about to fix a door" or an example like this. Pair codings help developers link their technical knowledge with regular communication, making them able to explain code to even non-technical people, and this is key to acing technical interviews.
What should you ask at the end?
This is purely relative to each and every interview, but you can say that questions that touch the uncovered parts are a good way to end an interview. For example, if the interview is about bananas and how they are planted, a good ending question would be: "Given that we successfully planted our bananas, how do you guys make them available to other people?" or something like that.
Questions that make it clear that you have well understood the topic of the interview to the point you can project yourself onto the future of the topic, this also leaves a good impression and shows that the candidate has grasped the problem at hand at deeper levels.
Find all of our latest engineering positions here.
Written by Hamza Ouaghad, Senior Software Engineer at expertlead.