In the first part of this post I covered the sort of preparation you can do before each interview. If you’ve read it and followed the advice you’re already going to be better prepared than most when going into your interview which hopefully will give you a good chance at getting the best outcome, but we haven’t covered what will happen at the interview itself. For many people the worst part of the interview is the unknown – not knowing what will happen and what questions they might ask you means that you can’t be sure how well you’ll deal with it. Unfortunately every interview is different so I can’t tell you exactly what will be asked, but in this article I’ll go through the general categories that most interview questions fall into and advice on how to prepare for and answer them.
Introductory Questions
These are part of the small talk that will happen as soon as you meet the interviewer and will generally focus on how you’re feeling, the journey in and whether you want a drink. Always accept the drink, even if you’re not thirsty at the time – you might find yourself with a dry mouth thirty minutes into the interview and nothing you can do about it, or if you’re asked a question that you can’t immediately think of an answer for, taking a sip of the drink can give you valuable seconds to get your brain in gear without looking too much like you’re stalling (it’s fine to leave the drink unfinished at the end of the interview). Your opinion on the journey in can range from ‘fine, no problems at all’ to ‘a little challenging but I’m sure it’ll be much easier now I’ve done it once’. Being too critical of the commute might convince the interviewer that there’s no chance you’d accept the job anyway and cause them to write you off before you’ve even got properly started.
Technical Questions
These are likely to be short, relatively simple questions with an obvious answer such as ‘What is object orientation?’ Don’t be surprised if these questions are very basic, even if you’re applying for a senior position. Firstly, there will be applicants who can’t answer them, perhaps people who’ve been less than truthful about their previous experience, so it’s important to the interviewer to filter those people out early. Secondly, it’s easier, and fairer to ask questions about something every software professional should be aware of, like polymorphism, rather than something about the use of an obscure class in their preferred framework, which you might never have had reason to use, even in a career spanning multiple decades.
If you have been working in software for some time, it might be helpful to look at some entry level training materials before the interview, just so that the answers come quickly and naturally, rather than requiring you to remember a concept you’ve used automatically without thinking about it for some time.
More advanced questions in this category might cover techniques and methodologies, like Agile, Test-First-Development, or Service Oriented Architecture. If you have these on your CV, or they are mentioned in the job spec, you should definitely have a short description of them prepared for the interviewer, however sometimes they might bring up something you haven’t prepared for. In this case it’s best to be honest. If you think you might know what it is, let them know you’re not sure, but let them know your guess. If you haven’t a clue, say that it’s not something you’ve come across before but you’d love a chance to learn it!
Work History Questions
Most interviews will include a discussion on your current job. This will include what you’re currently doing – the technologies you’re using and the sort of projects you’re working on, as well as why you’re looking to leave. What the interviewer really wants to hear is that you’re pretty much already doing the job they’re hiring for, except there’s something you dislike or find sub-optimal that will be better at their company. Because of that, it’s best to tailor the answer to the job spec for the new role – focus on technologies, techniques and methodologies that are common between the two roles, perhaps including one or two differences that the interviewer might be interested in, like a tool you’ve used and found effective that the new company might like to look in to.
When asked about why you’re looking to leave, hopefully it goes without saying that you need to be a little careful with your response. If you tell them you’re leaving because you hate your boss, the interviewer will wonder whether you’re likely to get on any better with your new boss. They are also unlikely to be impressed with being told you’re not paid enough, although if you can demonstrate that your current salary is significantly below market rates you might get away with it. Better answers include career progression (either moving directly to a more senior role, or the hope that there will be more opportunities to advance in the new company), better training opportunities or a chance to work with more interesting technologies, wanting to work in a larger or smaller company, admiring the company’s products or ethos and relocation to a new town (or reducing your commute). Obviously, you should only use one which applies to your current position – it’s not going to look good to say you’re looking to work in a larger company, if the interviewer can see that your existing company is the same size as their one. It also helps to be truthful where possible. Perhaps you’re mostly leaving because your boss is a nightmare to work for, but it would also be nice to work for a company that makes software to support ambulance drivers rather than software to train personal injury lawyers. If that’s the case, keep quiet on the first part and focus on the second!
Some interviewers will want to go back further and ask about earlier roles, so make sure you can remember at least the basics of what you were doing in all previous positions and why you moved on.
The Technical Test
Most interviews for a software professional will have some form of technical test. In general they take one of three forms – a written test, a coding test where you’re working directly on a computer, or, especially for more senior roles, a whiteboarding test where you’re expected to design something on a whiteboard.
In my opinion, the best is a pair-programming coding test where you’re given an existing project and either asked to find and fix bugs, or add a new feature. This is almost certainly the best simulation of what you would be doing in your day-to-day job which makes it more comfortable for you, as well as being the best demonstration of your abilities for the employer. There are two important things to do in this situation – talk, and listen. Make sure you understand exactly what you’ve been asked to before you start, and then announce what you’re going to do before you do it. This allows the interviewer to understand your thought process and also gives them the opportunity to nudge you in a different direction if you’re not doing what they wanted to see. So say, for example, “I’m going to launch the application in the debugger to see what happens” before you click the button, or “I think we probably need to modify the Widget class so I’m going to see what that code looks like”. The interviewer may make suggestions like “What about the WidgetManager class?” which push you in a better direction so pay attention to what they’re saying. Don’t fall into the trap of doubting yourself and changing direction every time they say something though – they might be looking for you to justify yourself and show that you have a deeper understanding of why you are writing code in a certain way than ‘because that’s what someone once told me to do’ so tell them if you think you’re in the right, but be prepared to back down if the interviewer becomes insistent. One common gotcha that can occur here is unit testing! If you’ve claimed to be the king or queen of test-driven-development, or they have mentioned how important it is to them (especially if they bring it up just before the test), going straight in and modifying the code without adding any unit tests won’t look good. If you’re not sure whether they’re looking for unit tests, ask!
Another type of coding test is where they give you a list of requirements and a code editor and they ask you to build a small application or website, probably unsupervised so that the interviewer can come back later and see what you’ve come up with. This is generally less representative of real-world work as in most companies you’ll be working on a small number of applications for many months, rather than creating a new one every day. If you are faced with a test like this, again it’s important to make sure you understand the requirements up front, asking questions if you have any uncertainties but then you just need to write the best code you can! Include unit tests, if they’ve been mentioned at any point in the interview. Make sure you create appropriate objects (in this one case, it doesn’t generally hurt to over-engineer – perhaps in the real world the app is so simple you’d write it all in one class, but that won’t demonstrate your fine grasp of object-orientation!). Comment appropriately and if there’s time, tidy up the code, grouping similar members and just generally making the code as attractive as possible. If it’s been a while since you started a new project, it wouldn’t hurt to open a code editor before the interview and just remind yourself how to start off a console, gui and web application so you can hit the ground running if you get this type of test.
Written tests are just the worst, they don’t represent how you will be working at all and score you based on how good your memory is rather than how good your technical skills are. However, if you’re presented with one in the interview that’s not the time to explain this. The rules here are similar to any other written test, read each question, re-read it to make sure you understand what’s being asked, and write your answer as legibly as possible. If there’s a question you’re not sure of, skip it in the first pass so that you can fill out more of the questions you do know quickly, then come back to it if there’s time at the end. Most of the questions are likely to be similar to the basic technical questions we mentioned you might be asked verbally in the first section, however they may include more complex, or specific questions as well. Don’t worry too much if you can’t answer all the questions, but be prepared to talk about them later. When you’ve completed the test, the interviewer may go through you answers with you. If you realise you’ve made a mistake, or that you could have answered a question better, you can bring it up at this point. If they point out a mistake, accept it with good grace, an acceptance that you can’t know everything and a hint that you will look forward to researching the topic when the interview’s over.
Whiteboard tests can be nerve-wracking if you’re not used to speaking in front of a group, but they can be fun too. In my experience, the most common tasks for this type of test are all based around drawing a class or component diagram, either for a system you have knowledge of, or a theoretical application. You might be asked to draw up a class diagram for an imaginary system that tracks vehicle movement, or to give a high-level overview of the software system you’re currently working on. Like with the pair-programming coding test the important thing here is to talk. As well as helping make sure you’re going down the path the interviewer wants you to, you’ll feel less anxious doing this if you are engaging with the interviewer rather than working in silence (and it’s more fun for them too!), so again, let the interviewer know your thought processes and what you’re going to draw before you do it, and listen to what the interviewer says – are they suggesting a better way to do something, or asking you to justify what you’ve got? Don’t be worried about getting everything perfect first time, much better to draw up something that’s not optimal than to get stuck in analysis paralysis and draw nothing. The great thing about the whiteboard test is that you can get the board eraser and correct mistakes if you realise that something isn’t working. Don’t get frustrated and wipe out everything though, unless you’re certain that you can get it right straight away next time. These tests are generally just to prove that you understand object orientation and/or modularity. If you’re doing a class diagram, don’t forget about interfaces and abstract classes. If you’re doing a component diagram, mention whether components sit on the UI layer, mid-tier, or back-end, including what could be hosted on separate servers if required.
Cliché questions
Fortunately in my experience, software professionals these days very rarely get the cliché questions, like ‘What are your major strengths and weaknesses?’ or ‘Where do you see yourself in 5 years time?’ but it’s not impossible that one or more of them will come up and as they are so well known it doesn’t hurt to prepare for them. I’d advise avoiding the cliché responses that used to be suggested – no-one believes that your major weakness is that you work too hard! But try to respond with humour and originality, without making the interviewer feel you’re mocking them for asking the question (although depending on how they phrase the question you might realise they’re asking due to an HR requirement, rather than any real interest in the answer, which gives you a little more leeway to have fun with it). The hardest of these is definitely the ‘weaknesses’ question and if you don’t feel you can deflect it with a toungue-in-cheek response like ‘I’m pretty sure I’m not bulletproof’ another good option is to bring up any minor health ailments you might have, or mention a technology you’re not fully up-to-speed on but could be if you were given the right training (bonus points if it’s a technology the job spec for the role listed as a ‘nice to have’).
Soft skills questions
These could be described as ‘tell me about a time..’ questions as they will almost always be looking for you to describe a situation where you’ve displayed a non-technical quality they’re looking for. It might be leadership, or dealing with conflict , pressure, or a tight deadline. The hardest ones focus on things that didn’t go well, asking about a failure or missed deadline and in that case it’s important to present the facts honestly, then focus on the lessons learnt from it. For me, with my uncooperative memory, these questions can be a nightmare as the interviewer will typically want enough details to be convinced that what you’re describing is a real event, rather than something you’ve made up on the spot to look good. The best way I’ve found to prepare for these types of questions is to spend a bit of time before the interview reminiscing about your last few jobs, thinking about the good times and the bad times, the people you enjoyed working with and the people who you were glad to leave behind. When you’re asked the question, feel free to pause before answering while you think of what you’re going to say but don’t be tempted to invent a story and present it as something that actually happened, if you really can’t think of anything suitable, say so, give a reason why you think you haven’t experienced it yet and say how you hope it would go if you experience it in the future.
The ‘any other questions?’ question
Many interviews will end with the interviewer asking you whether there’s anything else you need to know. Hopefully, if you’ve properly prepared for the interview, you’ll have a list of topics you wanted to cover and obviously this is a perfect time to fill in anything on that list that hasn’t been discussed yet. If something else has been mentioned in the interview that’s made you curious then bring that up too. This is probably not the time to bring up salary or benefits, unless the interviewer has already mentioned it. If they’ve already mentioned a salary that’s below what you would accept then asking whether there’s any flexibility can be fine (as if the answer’s ‘no’ you don’t want the job anyway), and if they’ve mentioned a fantastic benefits package but not gone into details you could ask about it here but in general I’d avoid it – you’ll get full details of salary and benefits if the offer comes through and if it doesn’t then the details don’t really matter. The worst possible answer to this questions is ‘No’ as it makes you appear uninterested in the process. Even if everything you wanted to ask has been covered already, try to think of one more question to ask. One good fall-back is ‘When can I expect to hear back from you after this interview?” but if that’s already been covered and you can’t come up with anything else on the spot, tell them what you were going to ask, but that they’ve already covered it, e.g. “Well I wanted to make sure I had a good understanding of how the team is structured and what technologies you use but you’ve already covered that really well, so thanks but I think I have all the information I need for now”.
The rest
There is also likely to be general discussion about the company and the role in which the interviewer will do most of the talking, however as mentioned previously, you should make sure that anything that is important to you does get mentioned at this stage.
You may get taken on a tour of the building, if this happens be sure to pay attention, especially when they get to the offices where you would be working – is it somewhere you could see yourself spending a significant amount of time going forward? Are the computers and other equipment reasonably up to date and well maintained? Do the people there seem happy (or as happy as can be expected while they’re at work)? Also check out how your potential colleagues are dressed and whether that fits in with your preference, whether you prefer a very casual dress code, or feel more comfortable in smarter office clothes.
So hopefully this guide has given you an idea of the sort of questions that might be asked and how you can handle them, both in terms of pre-interview preparation and what to do on the day. I’ve deliberately avoided listing word-for-word the questions you can expect to be asked as it’s impossible to predict what might be asked in any given interview and as soon as a given question appears on an interview questions list, interviewers start to avoid it. There may also be questions or experiences that I’ve not covered, but I think that if you’re prepared for all the types of questions covered here you’re probably prepared for the majority of the interview. Good luck putting this into practice and I hope it lands you your dream job!
