Software Engineering Interviews in 2021
After quitting my job at the end of September, I went through a whole bunch of interview processes. Given that I hadn’t done any for more than 3 years, I mostly forgot what they are like. It was a bit of a shock finding out again how annoying and time consuming they can be. That’s why I’ve decided to write down my thoughts and observations, so that I can be better prepared next time I’m looking for a job or maybe even organising interviews myself. My experiences are obviously biased, so please take this with a grain of salt.
A bit of Background
The first thing I did was obviously updating my CV and LinkedIn. Once I’ve done that, I started applying for senior engineer positions. Half of my applications came from recruiters that reached out to me on LinkedIn. This route tends to be a little bit faster as you can pretty much talk to the recruiter straight away. For the other half I’ve sent the applications in myself through the companies’ websites. This is not to say that applying directly is inherently slower, but it was generally the case in my experience.
The general Interview Process
The first step is usually a short call with the recruiter, where they introduce the company and their current initiatives, describe the interview process and ask some basic questions like expected salary and current notice period.
For some of the direct applications there was no chat with a recruiter and instead I went directly into an initial tech screening interview. In this type of interview you tend to talk to a technical person, answer generic or high level technical questions and talk about your experience in your current and previous roles. Sometimes you might also be asked some behavioural questions (more on those in a later section). This interview is a good opportunity to ask about the company’s tech stack, tooling and team structure, but you generally have the opportunity to ask about these in all of the following interviews. However, you might find something that you really don’t like at this stage, so you can decide to bail early on.
Assuming the previous stages went well, if they were not omitted, you will generally get 3 types of interviews afterwards. These are:
- Coding Interview (pairing exercise)
- Architecture Interview
- Behavioural Interview
Coding Interview
You have probably heard that companies like Google or Facebook like to ask tricky questions involving well known algorithms and data structures. I think there are plenty of resources about these, including some from the companies themselves, so I won’t go into too much detail here. Most other companies just want to see that you can write code and are even happy for you to look up stuff as you go or use your favourite editor or IDE.
The questions are usually pretty straight forward and you don’t necessarily need the optimal solution as long as you can produce a working one and explain its time and space complexity. It can be a few separate questions about manipulating strings or numbers, or a mini project like building a small command line application or an HTTP api.
It’s useful to be able to explain how you want to solve the problem and then talk through what you are doing as you are writing the code. It might not be super natural to everyone, so it might be worth practicing. Writing tests is not always necessary in interviews because of time constraints, but it’s good to at least mention how you would go about writing them.
Some companies still ask you to do a task on your own and then have an interview to talk through your solution. Only one company I’ve applied to asked me to do one. I’m personally not a fan of these take home tasks, so I was pretty happy that most of the companies I’ve applied to didn’t do them. I don’t like them because it’s hard to gauge what the interviewer is looking for and making a production-ready solution can take a huge amount of time. It’s also easy to miss or misunderstand part of the question.
Architecture Interview
This is a whiteboard session with a senior engineer or architect. The task is to design a high level solution for a complex problem or website. Quite often it’s directly related to the business of a company you are interviewing for (e.g. order or payments processing system). My usual approach is to start with something simple and then improve the design to tackle more load or improve resiliency. Making things asynchronous where possible is usually a good step to achieve that. It’s impossible to tackle all aspects of the design, so don’t worry too much about the little details. Interviewers will usually ask about the stuff they are interested in. Though it’s good to at least vaguely describe handling of communication errors like a failed API call.
Behavioural Interview
This is the least technical interview. It focuses on the way you work and your experience of handling different situations. It’s usually a fairly relaxed chat with a manager or a senior member of the team, where you get asked questions in the format of “Tell me about a time when…” or similar. Here are a few examples, but you can find plenty more with a simple Google search.
- Tell me about a time when something went wrong at work.
- Tell me about a time when you completed a project you were proud of.
- Tell me about a time when you disagreed with a team member.
One of the recruiters recommended this article that describes the STAR method for answering behavioural questions. If you are going through an interview process I would highly recommend that you give it a read. In short, the acronym stands for Situation, Task, Action and Result. The process is to first describe the situation to give context, then the task that you had to complete, followed by the action you took and finally the results you got. Following these steps at least vaguely makes for a clear story-like answer.
I found the hardest part of these interviews to be coming up with a suitable example. However, I think it was fine most of the time to talk through only a partially fitting one. My advice would be to think about some examples before the interview, but also to not be afraid to think for a bit when coming up with one. And also don’t be afraid to hype yourself up. It’s a job interview, it’s definitely not the time to be modest.
My Ideal Interview Process
Based on the steps I’ve just described, if I was to design an interview process I would go with something like this. Start with a short call with the recruiter, go through all the formalities and make sure that the candidate knows exactly what to expect going forward. It may potentially be the right time to stop if something like the salary for the role doesn’t match expectations. It’s also a good opportunity to give the applicant materials that can help them prepare for the interviews.
Then I would combine the tech screen and behavioural interviews into one. I would start with questions about the candidate’s experience, gauging their technical and leadership knowledge, and then transition into behavioural questions. Combining these makes sense to me as they are similar in nature, both focusing on past experience, achievements and learnings. Having one interview should make the process more efficient and the process can stop here if the interviewer doesn’t think the candidate is experienced enough.
Finally, I would keep the pair programming and architecture interviews pretty much the same. For the programming interview, I think it’s nice to give the candidate a basic idea about what the task is going to be, so they can prepare a little bit beforehand. For the architecture, I would try to come up with a design exercise that’s close to what the company does, maybe even based on what has already been built.
Note to the Recruiters (or whoever is managing the interviews)
Keeping the applicant informed about what’s going on and when they are going to hear from you makes a huge difference. Even if there is no decision yet or things got postponed for some reason, tell them that. It makes a really good impression as it makes the process very transparent and less stressful.
Some recruiters were better than others in this regard during my recent interviews. The recruiter from a company that did it best kept me informed throughout the process, giving me feedback as soon as possible after each interview and making sure I knew what’s coming next. Even when this person went on holiday someone else took over and kept me informed. At times it felt like it was maybe too much communication, but looking back it was actually very useful.
On the opposite end, there were recruiters who pretty much didn’t talk to me after the initial call and I had to chase them to find out when I’m going to hear back from them. In one instance I was told I will get the response on a given day and I didn’t hear from them at all until several days later. This wasn’t the nicest thing as it makes you wonder what’s going on. Did they not like me or are they just disorganised? Both are not very positive things.
In my ideal interview process, there would also be a recruiter keeping the candidate up to date about what’s happening. Ideally the process will be fairly fast, but even if for whatever reason it isn’t, the candidate will have a good idea when they are going to get the next interview or the final response.
Conclusion
I guess that’s all I have to say for now. I might update the article later on if I remember something else or get interesting feedback. For now I hope you found something useful if you got this far.
