More Software Interview Skills 101
Following on from my previous article[^] where I described various qualities that, whilst may be absent from a job description, are nevertheless important and worthwhile trying to gauge in an interview scenario.
This article will describe a few of the common mistakes I have run into whilst interviewing candidates for the role of a software developer. The points I will raise could probably apply to any candidate interviewing for any role though, as they are quite general in nature.
- You had better have done some research on the company before turning up for the interview. I actually had a candidate turn up to an interview a few years ago who hadn’t even looked at the company website. They knew nothing about the company or what we did. This is just plain rude. If a company is considering you for a role of employment, it doesn’t take much effort to do some basic research. I always do this, it’s courteous and shows a level of diligence and respect. You should always be able to answer the question “So what do you know about our company”. If you can’t, then go home.
- If you don’t know the answer to a question, don’t try to blag the answer. I don’t tend to ask questions about syntax or such like as I think they are a waste of time. I tend to favour more open-ended questions that ask what experience you have on a particular technology, or what you understand by a particular term or concept e.g. what do you understand by Test Driven Development. If you don’t know, it is far better to just say you don’t know. Trying to blag the answer just leaves the interviewer with the impression that this is how you will approach your work if you were offered the role. That you would just blag your way through your projects within the business. This does NOT set a good impression.
- Rambling answers that don’t really answer the question. Sometimes, if the candidate thinks they can answer the question, they will talk at great length and throw every buzzword into the answer that they can think of. So if the question was related to Test Driven Development, they might throw in Agile, Scrum and anything else that they think might give them brownie points. Keep your answers concise and on-topic. Giving a rambling answer that veers across many other topics and goes on for too long is not good for anyone. Use an example, give analogies, use your own experience. But just make sure you answer the question. And as with the previous point, a rambling answer does NOT set a good impression.
- Always have a few questions to ask. At the end of most interviews it is common for the interviewer to ask the candidate if they have any questions they would like to ask. It shows that you are interested in the role if you have a few of these, and especially if one of them relates to what has been discussed during the interview as it shows that you were paying attention. Don’t ask questions about salary as this shows you may be more motivated by money than the role. Ask instead about current projects or challenges faced by the development team for example. You could then follow this up with how your own knowledge and skills could help with these.
I have been interviewed many times, and so fully understand how nerve wracking the experience can be. I have had to write code, solve puzzles, fix an application that contained various errors, undertake aptitude tests, been grilled by technically very capable developers straight out of university, been interviewed by heads of department, directors, and everything in between. Mastering the black art of the interview is far from easy, but by following a few simple rules of thumb you can improve your chances of grabbing that dream role.
If this article was helpful to you, please do hit the 💚 button below. Thanks!
