The 6 Biggest Technical Interview Blunders
and how to avoid them
- Not prepared your intro
Most interviewers start off asking you to introduce yourself, this is the first impression they will have of you so make sure you prepare a short 2-minute introduction.
An introduction should include
Where you are currently working and your job title e.g. “I’m currently a Software Engineer at Goldman Sachs, leading a team of 5 for the last two years.”
What you are currently working on and key highlights e.g. “I’m working on the initial architecture of our reporting service and have just finished building out a messaging system which has scaled with our rapid growth.”
What technologies you are using e.g. “I’m a full-stack developer, primary working with Java for the backend and Javascript frameworks e.g. React for the frontend.”
- Not Asking clarifying questions
Listen intently and note any useful information in the question, then confirm the requirements from the interviewer and make sure you fully understand the problem, before coming up with a solution.
For example
If the question mentions sorted e.g. “sorted array” then it is highly likely that will be needed for the optimal solution
If the interviewer mentions inputs for a function make sure to clarify any boundary conditions e.g. interviewer mentions string input, you could ask “can null be passed as a parameter?” which will impact your solution
- Diving straight into a solution
I have seen many candidates start coding not long after the question, only to realise they will have to rewrite their code because they can optimize.
Stop. Think. Take a couple of minutes to come up with a brute force solution (without coding) which will get you thinking about the problem and your interviewer may give you advice, then optimise.
- Not Listening to the Interviewer
This is a simple one, but candidates can get focused on their code and not do this.
Listen to the interviewer, they have used this question multiple times and know it inside and out. If they propose an idea or say to look deeper into a certain section of code, there is always a reason.
Take a couple of minutes to think about their advice and how you can implement it in your code to optimize the solution.
- Not testing
Once you have finished your implementation, you are not done. The interviewer is looking at how you would work in the real world and after writing some code, the next step is testing.
Now the interviewer does not expect you to test every single permutation but first walk through your code with your interviewer, talking about what would happen at each step (an example will help).
Pay special attention to
Non-standard code e.g. x = length — 2; or for (int i=10; i>start; i--) make sure the values make sense when walking through your code
Arithmetic and null inputs/outputs e.g. x = (digit * 10) / 2 + 1 and ArrayIndexOutOfBounds Exceptions
Edge cases e.g. unexpected input convertStrToNum("test")
Once you find bugs, take a minute to understand why they have happened and how you would fix them. Do not patch up the code before thinking about the root cause, as you could be introducing more bugs or fixing a bug that should not have happened in the first place.
- Not saying Thank you
Thank the interviewer for their time. It’s polite and it goes a long way.
Bonus: Giving up
Don’t. Technical Interview questions are designed to be tough, you are not expected to get the optimal solution straight away.
Take a few minutes and talk through the solution with your interviewer, although all interviewers are different, they will usually give you some advice to keep you on track.
Thanks for reading! If you found this article useful or are looking to prepare for technical interviews, subscribe to my mailing list on my blog for useful articles and advice at bradleywinter.dev
