In the following post I will try to give some general advice on how to prepare for a software engineering interview. I am an active interviewer here at OVO and I have been doing this in the last 4 companies I have worked for, for more than 6 years now. I have seen some really good candidates failing to perform in an interview process and some people with not that impressive CVs nailing it. There are some common mistakes and fallacies that could definitely be avoided if people were aware of them. Finally since the process here at OVO is quite similar to the interview processes in companies like Google and Facebook (definitely more lightweight though) this advice can be applied in many different contexts.
Being good in an interview is a skill by itself. This means that you might be a really good developer but perform poorly in interviews. The other way round though cannot happen; if your skills are lacking, you won't be able to perform well in an interview no matter how relaxed you feel. You cannot cheat when going through a solid interview process. You should focus on improving your knowledge and skills first, and then try to become better at interviews later. On the other hand, if you are a competent software engineer that struggles with doing well in interviews... good news, you just need to spend some time in becoming better at it.
Let's start with the different stages that a software engineering interview process is comprised of: the pair coding stage, the technical architecture discussion part and the behavioural interview stage. It is crucial knowing what stage you are at, at any given moment, so that you know what is expected of you and how to nail it.
The Pair Coding
The pair coding stage is usually where we see the biggest drop out at OVO. There is one important thing that someone should do before going through a pair coding interview: practice. I cannot emphasize this enough. If you haven't coded for a while, then you must definitely do some practice beforehand. Especially if you are taking the interview in a different programming language than the one you currently use day to day, although most companies - including OVO - prompt the candidates to pick the language of their preference.
It is of vital importance though to practice under realistic circumstances. This means solving exercises with a time limit, or explaining your code while you write it. You can do this with a friend or you could use an online platform for mock interviews. InterviewBit and Pramp are some really good ones, that you could either code with time constraints or get interviewed by a fellow candidate.
Aside from practicing, some things that you should have in mind during the interview are:
Hurry up, take your time.
- This is apparently an oxymoron, but the idea is that although you should be mindful of the time constraints and try to manage your time wisely, it is also equally important taking your time in understanding the question in place. Some questions may have "traps" or be intentionally vague, so asking clarifying questions may be the only way to reach a correct solution.
Take testing into account.
- Try to write at least a couple of tests, or even describe how you would test your code. Writing the code in a full Test Driven Development manner would be ideal, but sometimes is not a viable option during an interview, considering the time costraints. Nevertheless, showing that you are mindful of testing shows a very important virtue for a software developer.
Never think that you are done.
- 'Off by one' errors and bugs are really easy to miss during the admittedly stressful process of a pair coding exercise. Always double and triple check the code you have written and perform in your mind a test run of the code for some input. If you have time try to write some more tests covering edge cases.
The interviewer is your friend.
- Always try to think out loud, communicating your way of thinking. Listen carefully for hints that the interviewer might give you, or even any positive reinforcement ("sounds good", "let's try that", etc.). As an interviewer this is something that I value a lot as it is a strong indication of how good the candidate is at collaborating.
The Technical Architecture discussion
This is something that most people underestimate. It involves discussing the abstract design of a system that either the candidate has been involved in the past, or a system that should be designed on the spot. Becoming good in designing systems is a skill that takes years to harness.
While designing a system, the most challenging thing is usually scaling. If it is a web based system, how would you scale your web servers to handle thousands of requests per second? What type of storage would you choose? Raw files, SQL, NoSQL? Why? Can you recognise single points of failure? How can you guarantee the resilience of your system? These are questions that you might be asked to answer. If it is a project that you have been involved, you should be able to go into depth regarding the parts of the system that you were part of/developed. If it is a system that you are required to design on the spot make sure that you fully understand the requirements and the expected functionality of it. If not ask questions! It is also ok to make assumptions (eg. let's say that the users will be located only in the UK), as long as you state them explicitly and the interviewer accepts them.
In this type of interview the candidate should be leading the conversation. Some resources that might help you, can be found here and here.
The Behavioural interview
Many software engineers do not feel that this is a stage that challenges them. However, it is a very important part of the process and can cost to a candidate getting an offer even though they have been successful in the technical parts. The behavioural interview covers a range of topics; including communication and teamwork, as well as technical influence and ownership. Can you communicate efficiently? Can you be part of a successful team? How do you influence your team and others to move forwards and deliver value? Don't make the mistake and believe that you should lie though, in order to impress the interviewer - experienced interviewers can easily smell bs. You will be much more successful if you just be yourself. And in most cases it's not about impressing the person sitting opposite you, but rather not giving a reason not to like you (ie. "a red flag").
Many people give canned answers to questions that don't exactly fit, this is usually something that backfires. Having said that, it is very important to self-reflect and consider what has worked for you throughout your career. When did you enjoy the most in being part of a team? What was the impact of the project you led? What mistakes did you make and what things could be done better next time? This self-reflection will not only help you in doing well in a behavioural interview, but will help you also become a better professional.
Finding the right fit
The best way to feel confident and able to tell the truth in an interview is to find a company that you are excited to work at and has an ethos that you believe in. For me that is OVO Energy.
Working as a software engineer at OVO is a dream job. OVO recently won a Top Employer certificate for a second running time. The level of the software engineers here is world class. People who work here have written books, present in conferences and are the core maintainers of the hottest open source libraries for functional programming. Moreover, OVO's mission statement is to provide abundant green energy to everybody, a rather noble vision. Thus if you want to be amongst really competent developers, under a great working environment and in a job that will give you purpose (making the world a better place one line of code at a time), OVO is the place to be.
Now that you know how to nail that interview, go ahead and apply! That dream job at OVO is waiting for you: https://www.ovoenergy.com/careers/vacancies
Special thanks to Emily Rigby for taking the time to review this blog post.