Recently I have been doing a lot of interviewing (and we are still hiring), and I have seen a large difference in the interview skills of developers. There have been great candidates have struggled to show that in interviews, and every single candidate could have done more to stand out from the crowd.

I am talking to developers in this post, not because I'm going to be talking specifically about answering software development questions, as there's a huge variety in the questions that are asked, and there are plenty of posts and books that already talk about that. Your technical knowledge is what it is, but there are tips on interview technique that can help you better convince the interviewer that you have the right set of skills for them. These techniques likely apply beyond developers, but I am talking about what I know.

Always remember that you are always interviewing the company as well as them interviewing you. By more fully engaging during the interview process you will have more information to decide if you want to work there. Your circumstances will dictate how much choice you have in that matter, but you should always know what sort of company you are interviewing at.

Before the interview

There are several things that you can do before the interview that will both allow you to be better prepared, and to demonstrate that you are thoughtful, motivated, and detail oriented.

Ask some questions about the interview

Someone will be talking to you to schedule the interview, and the amount of information they provide will vary widely. You want to ask for some more information from them so that you are better aware of how the interview will work, and what will be covered.

You should always make sure you understand some basic information:

  • When the interview is
  • Where is it? Do you have all the info needed to get there, or join if it is a video call?
  • Who the interview is with. You want to understand how many people will be interviewing you, and find out their names and job titles.
  • What the interview will cover. Some companies will give you a list of questions, but most will not. They should always be willing to tell you something though. I would be wary of interviewing somewhere that asked you to prepare for an interview that could be on any topic whatsoever. At the very least you should understand whether it is a technical interview or not.

Just avoid coming across as too pushy, or trying to get access to the answers, limit yourself to one or two rounds of questions and most people will consider that a good thing and answer, any more than that and you are risking coming across as being pushy or lacking confidence.

Prepare some questions

Every interview should end with the interviewers giving you a chance to ask some questions. Often 10 minutes will be left at the end of the interview for this. You don't want to be caught off guard at this point, as the interviewers will be evaluating the questions that you ask.

There should be plenty of things that you want to know about the company, so start by writing all of those down. Next identify the ones that can be answered by information available online and get searching those answers. Asking about something that is easily findable on the company website won't make you look good, and you also don't want to waste your time asking about this so that you can ask about the things that you can't find online. You want to do that research now as it will better prepare you for the interview.

You should be left with a list of things that you want to know that can't be found in a search engine. For each try to think of questions that would help you understand that aspect of the company. Obviously you aren't always going to be able to get a complete and clear answer to a straight question, but you can think of questions that will give you some idea. For instance if you are interested in work/life balance, you can ask "when was the last time that you worked late?", or "when was the last time that your manager told you to take a day off?"

Once you have a list of questions pick five that are tailored to the people that you are speaking to. You will likely want to ask different questions to future teammates, the hiring manager, the executive, HR, etc. You can ask the same questions to multiple people, but try and avoid having a fixed set of questions that you ask in every interview for the same company, as each time you ask them you will learn less.

By asking good questions you will both learn more about the company, but also come across as a candidate that is thoughtful and very interested in the role. I'm always a little disappointed when a candidate has zero questions at the end of an interview.

Prepare some answers

You should also spend some time thinking about the answers that you are going to give in the interview. You probably don't know the questions that they are going to ask, but the recon that you did earlier will give you some ideas. You know:

  • What they say the subject of the interview is
  • Who the interviewers are
  • What the job description says
  • What the company does

By putting these together you should be able to guess some of the topics that will be covered, and maybe the sorts of questions they will ask about that topic.

If you know that you are meeting with the lead of the db team, then expect some database questions. If the role says that a responsibility of the job will be automated testing of a data pipeline, then expect some questions about automated testing of data pipelines. If the company uses Ruby to manage IoT devices then expect some questions about Ruby and IoT protocols.

Of course your guesses won't all be correct, but you will be close on some of the things, and the process of thinking about it will be useful either way.

Once you have your list of topics and/or questions you can think about experience you have with those things. It's rare that an interview asks entirely about factual things, and there will almost always be questions about your experience with a topic, so already having thought about which stories from your past may be appropriate should avoid your mind going blank at the crucial moment.

This applies to non-technical interviews as well. You can think about experiences related to demonstrating leadership, resolving conflict etc. and have those stories ready if asked about those topics.

During the interview

Once you get in the interview there are several bits of interview technique that will help you to demonstrate your skills. A very common problem is failing to understand how to shape the interview and your answers to demonstrate a well-rounded skill-set and experience.

Expect a brief chat at the beginning

Expect there to be some small talk at the start of the interview, particularly when dealing with multiple interviewers as they may not arrive at the same time.

You want the interviewer to like you and see themselves working with you, and this will have a large impact on that. Unfortunately it may also be the point in the interview when you are most nervous, so having something prepared may be a good idea.

Go in to the interview with a question or two that you can use at this point. You can ask about anything, such as the weather, the commute, lunch, or their role, or some relevant news story. Ideally you should be able to engage in a brief chat that helps put you at ease.

Sometimes you will find that the chat at the beginning seems to be going on far too long. This could be for two reasons. Firstly that you have engaged someone that talks a lot in to an interesting conversation. In that case try and let the conversation come to a natural close pretty quickly, for instance following up to the next thing they say with "yeah, it's a very interesting topic" and then pausing to provide a break to move on to the interview. If that doesn't work it may be because you have found yourself in the second case, which is where the interviewer is going for a conversational style interview, where they just start a conversation and see where it leads. If you think that's the case then try and get your brain out of small talk mode and in to interview mode and start trying to shape your answers using the rest of these tips.

Give well-rounded answers

Each question the interviewer asks has two purposes:

  1. a specific question that they want to get the answer to
  2. a placeholder for a topic that they want to discuss with you

In giving your answers you need to address both of these at the same time, which can be tricky, but can come quite naturally with some practice.

The first thing you want to do in response to a question is think. You need to pause to let this happen, so don't jump straight in. Some people take a sip of water, some say "let me think..."

In this period ask yourself two questions:

  1. What does the interviewer want to hear?
  2. They will have some particular things that they will be listening out for, can you work out what they are?
  3. What do I want them to know about this topic?
  4. As well as answering their question it's also an opportunity to tell them about some of your skills or experience. What seems important for them to hear at this point. For instance as well as answering their question you might want to show that you have a deeper understanding.

As you are doing this you may realise that you don't really understand what they are looking for, in which case you should clarify the question. Don't be afraid to do this, and it's actually a marker of someone that communicates well. You can ask them to repeat if you didn't hear, rephrase if you don't really understand, or clarify if there's a point that doesn't seem clear.

Once you know what you want to talk about then structure your answer. There is some real skill in doing this well, so having some mock interviews can really help. You want to concisely answer their question while also showing that you know a bit more than that.

One of the best answers a candidate ever gave me was in an interview where we had been discussing the code of a personal project they had worked on. I asked "what would be the next change you would want to make to this code?" They answered by listing some of the changes that they would want to make and why. They wrapped up their answer by saying "...but you asked me what was the next change I want to make to this project, and that would be [...] because it would make all of the other changes easier and safer."

This was a fantastic answer because it showed:

  • That they have lots of ideas for improvement
  • That they listened to and understood the question
  • That they had thought about the priority of the changes, and why one would be good to do before the rest

This is a great example of both answering the question and saying what the interviewer wants to hear, as well as being able to show some more depth behind the answer, wrapped up with excellent communication skills.

Experience beats knowledge

Someone that has experience with a topic is generally preferable to someone that only knows about it in theory, so when possible you should tie your answer back to some experience you have had.

A good technique for this is to start the answer with your specific experience, and then talk about what you would do differently next time, as this allows you to demonstrate that you learned from the experience and would be able to apply that.

The only danger is if you have the same example for every question. If you are just starting out your career that is fine. If you are not then try and have some variety, though drawing more from the most recent examples makes sense as that will be when you knew the most, as well as it being fresher in your memory.

Don't overlook the simple stuff

One trap people fall in to is overlooking the simple things, they always want to dazzle with their knowledge, but there are two problems with this.

Firstly the thing that you think is simple may be exactly the point that the interviewer is looking for you to make. By skipping over it the interviewer thinks that you don't know the answer.

Secondly, trying to dazzle isn't all that effective as it can look like you are trying to show off, which people generally don't want in a colleague. The best developers I have interviewed were able to quickly and simply communicate the simple answers and move on to deeper things. This is usually a good tactic when constructing answers. You give the simple answer and phrase it really well, and then start unpicking the complications and talking about them. The interviewer can then move on when they feel that they have heard enough.

Tie your answers back to the role

You know something about the company and the role that you have applied for, so you should be able to make some reference to what you would do if you were working in that role.

This can be things like saying "I guess that in your industry latency is critical, so I would make a different decision in that case," or "I learned from that how to troubleshoot gRPC services, and I would be able to bring that skill to this role."

The only thing to be careful of here is telling the interviewers how to do their job. Make your statements hypothetical, or make it clear that you are guessing about the constraints that they have.

Don't be afraid to say that you don't know

A big danger is trying to pretend you know something that you don't. You can very quickly get caught in this, and it does not reflect well on you.

Once you are pushing past your area of knowledge then don't be afraid to say that you don't know.

You don't have to stop at that point though, you can try and demonstrate that while you don't know something for sure, you still understand some of the context.

One option is to ask the interviewer something. This works best for something simple, e.g. you can't remember whether Prometheus uses push-based or pull-based collection because you haven't used it yourself. You can ask for clarification and then continue from there. Most interviewers will be fine with this as you demonstrated that you understood the difference, and just couldn't remember a simple fact, but were able to recover.

The other option is to switch to hypothetical mode. You can say something like "I don't know how that system works, but I think if it's based on X then it would handle that by ..." Don't go too far down this path, but it's a way to avoid just saying "I don't know" and show that you understand some of the concepts.

Pacing

In some ways this is the hardest skill here. It's in your best interest that the interviewer makes it through all of their questions, but you also don't want to finish early and not have as much time to sell yourself. This is hard as you don't know what is coming.

It's also tricky as interviewers have different styles. There are some people that ask a question and listen to your answer, then move on to the next question. There are others that want to make the interview more conversational and ask the first part of a question and then want to ask a follow-up based on your answer. It's important to try and figure out which type of interviewer you have. If you give short answers to the first type then the interview will be over very quickly. If you give long answers to the second then the interview will drag on, but also they won't feel that the conversation was very fluid, and that's something that this type of interviewer will usually be grading on.

My advice for doing this is to answer the first question in a pretty straightforward, to-the-point manner. Don't rush, but don't spend lots of time on digressions and details. If the interviewer moves on to the next question then they are likely going to continue in that fashion, so focus a bit more on fleshing out your answers to say the things that you want to convey to the interviewer. If they instead ask a followup then you likely have a more conversational style interviewer and you should give opportunity for the interviewer to ask followups and have a conversation.

Overall try and keep half an eye on the time, and also on the demeanour of the interviewer. If they are looking rushed then try and speed up a bit and hit more directly on the main points you want to make. If there seems to be plenty of time left then you should expand on your answers a bit more.

In a typical hour-long interview there will be 10 minutes for questions at the end, so you should have the 45 minute mark in your mind as the wrap up point for the questions.

If all else fails then you can ask the interviewer how you are doing for time.

If you do find that you have finished the interview super early then feel free to say something like "Now that I've had a little more time to think about it there's something I would like to add to my answer about X, could we go back to that please?" to allow you some more time to demonstrate your knowledge.

Summary

My main points of advice would be:

  • Preparation is important to a great interview
  • You are interviewing the company as well as them interviewing you, so ask good questions
  • Think about what the interviewer wants to hear, and what you want them to know about you, and try and structure your answer to do both these things at once.