By Martin Cartledge

In my last article, I shared my thoughts on how to get an interview as a software developer. This week, I will share my thoughts on how you should prepare for that interview once you get it.

Tech interviews are notoriously nerve-racking and unpredictable. But there are steps you can take to mitigate a lot of these feelings.

Phases of the interview process

Most software development interviews have a similar structure - it's kind of like the modern foundation for these interviews.

You'll typically find the following phases in your interview process:

Phone screen
Technical phone interview
On-site

Let's look at each of these in a bit more depth.

What questions should I expect?

Interviews in the tech industry are far from uniform, but I like to think of that as a positive thing. This keeps things interesting and can allow you to show off your skills in a new way each time.

This includes the questions that you will most likely be asked in your interview, but don't worry. There are lots of common questions that will help you be prepared for your big day.

From my perspective, these questions can be broken down into two categories, company-specific and situational (hypothetical).

Company-specific questions

Depending on the size and type of company you are interviewing at, the way they interview might differ. I suggest you use websites such as Blind or Glassdoor to gain insight into company-specific interview topics and questions.

As an example, The Interview Guys put together a great article that discusses Amazon's top interview questions.

If you spend a little bit of time searching around on the web, you should be able to find some questions that a certain company traditionally asks. This will give you a leg up on your preparation.

Situational (hypothetical) questions

You can expect these questions to touch on your work style, recent achievements, and your technical competency. A few topics that you can expect to be asked about are:

Tell me about a time that you had to deal with a tricky bug. How did you fix it? What was the outcome?
Do you prefer to work by collaborating (pairing) with others or on your own?
What do you like about the programming language you use?
Which new features of the language do you use most and why?
Describe your team’s typical workflow for a project. What do you like about it? What don’t you like about it?

Remember, stay positive as much as you can. Although the interviewer is genuinely interested in your responses, they are also looking for any signs of negativity or difficulty you might bring into their current team dynamic.

Try to avoid talking down about a particular piece of technology you have used in the past. Instead, spin your response in a positive way.

For example, instead of saying “I don’t like using the spread operator in JavaScript, it’s too confusing”, you can say, “I know the spread operator is a newer feature of JavaScript, I look forward to learning more about it and how to use it efficiently in my code.”

Now that you have a good idea of what some common questions are and some elements to include in your responses, let's dive into each step in the interview process. The first step is the phone screen.

First things first, "tell me about yourself"

After you apply and a company has an interest in you, the first step is usually to schedule a phone interview. This is typically a pretty relaxed conversation with a member of HR.

You can expect them to ask primarily about your job history, what you are looking for next, and most importantly, why you are applying for a position at their company.

Just because this is typically easier than the other phases of the interview process does not mean you should not prepare for it. A few questions to prepare for are:

Tell me a little bit about yourself

This is a good time to give your “elevator pitch”. This will likely be one of the first questions you are asked and usually can be a great tone-setter for the remainder of the interview.

If you tend to talk fast, take a deep breath before you answer and try to speak slowly and clearly. A few items you want to mention in your response are:

Ethos or interests you share with the company
What excites you about software development
Future goals that (hopefully) this company can help fulfill (that is, technical and professional growth)

What is a recent project you worked on that you are proud of?

Like most of these questions, the interviewer is not solely curious about your technical achievements. They are also looking for cues that convey you can communicate well, are reliable, and are someone who would get along with the other members of the team.

Try to be enthusiastic and answer questions fully, without rambling too much. An effective framework for answering these types of questions is:

Give a quick overview of what the project is and the problem it solves
Mention the technologies you used in this project
Communicate any metrics that demonstrate any positive impact (like time-saving metrics, open-source contributors, number of active users)

Why are you looking to leave your current company?

This might be one of the trickier questions to answer. Make sure you have a solid answer for this one prepared prior to the interview, as it can tell a lot about a candidate pretty quickly.

Here are a few things you should avoid when answering this question:

Being negative. Turn any potentially negative factor into a positive one. For example, “I am bored and unsatisfied with the work I do here” can be said instead like, “I am looking for a new challenge that cultivates my growth as a developer and an individual”.
Talking about current coworkers or managers – keep them out of the conversation
Discussing compensation and benefits

I think one of the best answers you can give to this question is an honest one – you are looking for something new. That is a perfectly reasonable answer!

The only pieces I might add to this response are your interest in new challenges, enthusiasm for the company, or a piece of technology that you know this company uses.

How to prepare for the technical phone interview

Ok, you were enthusiastic, personable, and well prepared for your phone interview. The next step in this process is generally a technical phone interview.

Before your technical phone interview, it's important to make sure you know which programming language you will use.

Which programming language should I use?

Before you start preparing for the other steps of the interview process, it would be prudent to have a good idea of which programming language you will use during the interview.

When it comes to this question, I have some pretty simple advice: embrace what you are comfortable with, and stick to what you know.

It is fairly common to want to use (or learn) multiple languages in our field. But, when preparing for an interview, it is best to stick with just one.

This will help shift your focus from worrying about which language you will use, to thinking of problems you have solved with the language you are most comfortable with.

Once you know which programming language you will use, you are ready to take on the challenge of the technical phone interview.

Discussing technical achievements and high-level programming topics

In a typical technical phone interview, you'll have a conversation with a senior member of the team you would join or with the manager of that team. You can expect a lot of this conversation to be focused on two things:

Recent problems you have experienced in your current position and the solutions you implemented for them, and
General language familiarity (such as when would you want to use an array instead of a hash table (object)?)

To help prepare for this interview, I suggest you start to write down answers to these questions.

Personally, I have used an Excel or Google sheet document that consists of 3 columns: questions, answers, and notes. You will find that taking the action of writing your answers down will help you come up with a concise and impactful answer.

There are a lot of resources online that list common interview questions, for frontend, backend, or full-stack roles.

This might seem like a lot of work upfront, but trust me – spending the time to prepare and convert your thoughts to pen and paper will really help you mentally flesh out your answers.

Okay, you've spent ample time preparing and you impressed your interviewer! The next step you can expect is the "on-site" interview.

What is the on-site interview all about?

The final stage of the interview process is usually referred to as the on-site. This is often the most in-depth and the most important to perform well at.

One of the main questions the company would like to have a good answer for is, how does this person work? The answer to this question is usually echoed through multiple levels as well, personal, technical, and professional.

Companies seek this answer by giving the candidate various exercises, technical and interpersonal, to gauge your skills and how well you will fit in at their company.

Depending on the company this interview can include various elements, but a few that are most common are:

Pair programming
Take-home assignments
Whiteboarding

Excel during your pair programming session

One of the most common methods of gauging your skills is to pair program with a member of the team you might work with.

This session is usually 20 to 30 minutes and the problem you are given is generally something you will see on the job at this company.

There are a few things to keep in mind if you have a session like this:

Try to stay calm and remember that you are interviewing here for a reason, they like you and see promise in you.
Communicate out loud as much as possible, even if you think you are talking too much. It’s better to over-communicate in these exercises than to sit in silence typing away at the keyboard.
Don’t be afraid to ask questions, they’re on your side! The interviewer has probably left out critical details on purpose to test your communication skills while working with other developers.

Ultimately, try and be conscious of the fact that this company sees promise in you on a personal and technical level. Be yourself and be confident!

If the company does not have a pair programming exercise included in their process, another common exercise is to give you a project or a collection of problems to solve on your own.

Crush your take-home assignment

If the company wants to gauge your work through the lens of how you work as an individual, they might ask you to complete a take-home assignment.

These can range from completing timed exercises on HackerRank to completing a small project with written instructions from the interviewer themselves.

Regardless of the style of take-home assignment, there are a few things I think you should keep in mind to increase your chances of success:

Ensure you are in a distraction-free area for the entire allotted time
Put any distraction-prone devices away
Read all instructions to the problem(s), and then read them again

If your assignment is timed and you do not think you will have enough time to finish, write comments throughout the assignment with what your next steps would be if you had more time.

To be honest, a lot of these assignments are supposed to take longer than the scheduled time to complete.

The interviewer is always primarily focused on how you communicate, not that you can write code the fastest, or solve every algorithm you see.

Conquer the whiteboard exercise

Sometimes a company would prefer to take a look at your technical skills and ability to break down complex problems in more of an abstract way. The most common way of testing a candidate this way is by having them complete a whiteboard exercise.

This method of interviewing might be the most talked about, and the most feared. If you are asked to use a whiteboard to solve a question remember this: they are (usually) far more interested in how you communicate your problem-solving process, not that you can solve the problem.

If the problem they give you seems really hard, that is not because they are trying to stump you. They want to get a feel for how you tackle a hard problem. If you don’t end up solving the problem, that does not mean you blew your chance.

If you keep these things in mind during this exercise, it will increase your chances of impressing your interviewer:

Repeat the question back to the interviewer
Ask clarifying question about edge cases
Confirm optimal results of the problem
Write your code legibly
Communicate each step you take

If you answered the question successfully by the time the session ends, ask your interviewer if that was the solution they commonly got. If not, ask what other candidates have done or what you could have done differently. This shows that you are engaged and curious.

If you did not answer the question successfully, write comments throughout the code about where you might continue to find the solution if you had more time. Again, a lot of these sessions are not focused solely on getting the “right” answer, but to get a good idea of how you approach new problems.

Practice interviewing, without the pressure

As I mentioned earlier, interviews are tough and can be hard to prepare for. However, I am a firm believer that the best way to ensure a higher chance of success is to practice, practice, practice.

Have you ever practiced a big presentation for school in front of friends or family? You might have still been nervous but, it sure does help you feel more comfortable speaking about your topic.

Interviewing is also a presentation, and the concept of practice runs are just as important. In the 2020 world, most interviews are completed remotely, which makes performing mock interviews feel more real.

If you know someone who is currently in the software industry, I would ask them if they would be willing to set aside an hour or so a week to perform these mock interviews with you. If they currently work in a similar role that you are interviewing for, even better!

A few other options are Pramp and CodeInterview. These sites allow you to schedule an interview, and pick a primary focus (topic), language, and area of expertise (frontend, backend, and so on).

These platforms also give you more flexibility so you do not have to worry about scheduling time with someone you personally know.

Interviews are nerve-racking, but I am confident as you complete more of them your confidence and comfort level will increase.

Should I cram the day before?

As the days go by, you are feeling more confident. You are tired from preparation, but excited to show this company what you are made of. It's finally the day before the interview – what is the best use of your time?

It might be tempting for candidates to cram as many Leetcode problems or whiteboard questions as possible the day before. But I believe the best thing you can do for your mind is to rest.

Celebrate your achievement, getting interviews is not an easy task. Be nice to yourself. Relax and spend the day doing any activity that brings you joy and (ideally) relaxes you.

This might sound counterintuitive, but I think it is the best thing for you to do. You will need your brain to work well at your interview. Therefore, giving it rest the day before is exactly what it needs.

In Summary

If you are reading this because you are going to start to prepare for an interview, congrats! I hope my insights can help in your preparation and your headspace as you approach your big day.

Ultimately, remember to take a deep breath, relax, and be confident in yourself. Whoever you interview with sees promise in your skills. You got this!

How to Prepare for a Software Developer Interview