Tips for a successful interview in the games industry

You've made it through the application selection and have been invited for an interview for your dream role. This is just the beginning of a long and stressful process where your hard and soft skills will be constantly evaluated through a series of tests.

Being interviewed is something all of us will have to go through multiple times throughout our careers, but it can be daunting even for the most seasoned professionals.

Not only have I been through plenty of interview processes as an interviewee, but I also regularly interview candidates for programming vacancies at Splash Damage. As another hiring period is about to begin, I would like to share a few pointers and tips based on my experience interviewing candidates. Don't expect a "ten tips to get the job" type of post, rather a collection of observed behaviours that can lead to an unsuccessful interview.

The interview structure and what to expect

Typically, an engineering interview assesses a candidate on different key areas: future aspirations, technical skills, analytical thinking/problem solving, and communication. Although all sessions will aim to collect information about these areas, this is done in different depths depending on the stage you are in.

• The screening call

A short call, up to 60 minutes. The aim is for the interviewer to understand your motivation for applying to the company and to get a better idea of your overall experience. The interviewer may also probe your knowledge, so there may be a few technical questions as part of this call although they usually will remain fairly surface level.

• The technical interview

As the name implies, this stage will focus on assessing your technical knowledge. There are different variations of technical interviews including calls that last for approximately 90 to 120 minutes or take-home tasks, which can take up to one week to complete. The aim of this stage is to see if you are familiar with the technology the company is using and what practises you follow. Expect whiteboard tests, a buddy-coding session, and technical questions related to the field (maths, physics, computer science -- you name it).

There is a misconception that if you pass the technical you have pretty much landed the job

• The cultural fit

The final interview stage can also often be long. There is a misconception that if you pass the technical you have pretty much landed the job. That is not accurate since companies value an appropriate "fit" with the team.

In this session you will have 1:1 conversations with people outside of your discipline (e.g. producers, designers, artists). These are most likely the people that you will be working closely with and are interested to know how you handle things in your ordinary workflow. Again, you can expect technical questions and/or whiteboard tests. This stage can last upwards of 120 minutes.

The outcome of each stage is not only affected by the interactions you have during the call, but instead it is the sum of your actions prior, during and after the interview.

Before the interview

• Do your research and figure out your motivation

Before applying to a company, you need to know why you want to work there as you will likely be asked this during the screening call.

- What to do: Ideally, you want to work somewhere you feel passionate about or you can relate to in some way. You might be keen on the tech they are using or developing, their methodologies, or the products themselves. The important thing is to be honest. If you talk about the company's products, be prepared to be asked further questions about them.

- What to avoid: Never say that you applied because you were "CV spamming", or that you want to move to the place where the company is located. I have heard these before, and they don't give a good impression. Instead, try to find a good reason that makes sense and that you truly believe.

• Prepare your CV

As engineers, we like for things to be in "order." Make your CV reflect that and tailor it for the position you are applying for. An interviewer will dig through it, as they are trying to understand the areas they will focus on during the assessment.

Raw text documents area big bold NO as they show lack of professionalism and enthusiasm

- What to do: Make sure you submit in a format that is appropriate. PDF documents are the norm. Word documents are acceptable although they might not display properly on all devices. Make sure any portfolio or project links within your CV work as hiring managers will most likely go through them.

- What to avoid: Raw text documents (such as a .txt file) area big bold NO as they show lack of professionalism and enthusiasm for the role and company. Avoid statements like "Expert in C++" -- something that no one can really say.

Do not include a chart showing the level of proficiency and skills -- what does "C# experience 8.5/10" really mean? Trim the excess fat and don't try to oversell yourself. I have interviewed people who have claimed skills and experience they did not have, leaving a bad impression overall. Hiring managers are realistic and they understand what experience to expect for different levels. Using a list layout or grouping skills together is enough in most cases (e.g. Experience: Unity3D/C#, Unreal Engine 4/Blueprints/C++, and so on)

• Know who you will be speaking with

Feel free to lookup your interviewers and understand where they fit with the company you are applying to. There is nothing wrong with you looking up your interviewers' LinkedIn profile or personal website. It shows interest and it is a good idea for you to know their background too.

That said, you should keep this as a background research and avoid approaching them directly, unless you have been told it is acceptable to do so.

• Do your "homework"

Interviews are not -- or should not be -- designed to make you fail, but you do need to be prepared. Instead, they are meant to test your skillset. As mentioned earlier, they cover both technical and soft skills, so you must always be prepared to answer questions related to both. Even people with significant experience can fail an interview if they come underprepared. Researching the company, their hiring practices, and the role can give you a good idea of what you can expect.

• Test your setup beforehand

Typically, before an interview you will already know what you will need to have at your disposal. Make sure that you are on a stable internet connection with good bandwidth. Make sure your microphone and camera are working properly. It can be difficult to connect with your interviewer(s) over audio alone so aim to be on video if possible.

In the case of a live coding test, make sure that the IDE you are meant to use is setup and you are already familiar with it. A good idea would be to also have a notepad if you need to visualise something. Even better, consider using a shared whiteboard so interviewers can see your notes too. Using this approach, you make sure that there won't be any misconception that you have been looking at notes during the session.

During the interview

• Don't try to cheat your way through it

You might be surprised that I even have to mention this, but it does happen! Looking at notes or using online search is strictly prohibited. There might be some companies that allow notes, although none that I have ever come across.

If in doubt, ask your interviewers before you begin. Being clear on if this is permissible is much better than doing so without asking. Remember, in most cases the interviewer will be able to tell if you are looking at your notes and would definitely red flag the session. Avoid, avoid, avoid!

• Don't rush -- take your time to think

As mentioned above, a typical technical interview can last between 90 and 120 minutes. There is a reason these interviews take so long. Nobody expects you to fire off answers like a robot! It is useful to take time to think about your answer before responding. There are some companies that do a 20 rapid fire question session to assess how you are thinking under pressure. Even so, the time you are meant to spend in each section has some margin for you to provide a comprehensive answer.

I have come across candidates that either try to provide an answer quickly or, even worse, try to guess the question while the interviewer is still explaining. This is incredibly frustrating and will not win you any points with the interviewer!

• Be creative and avoid textbook answers

Again, take time to analyse the question before answering. Try not to provide an answer straight out of a textbook.

This obviously does not apply to everything. If the question revolves around the formula to calculate the dot product there is not much room for creativity. On the other hand, there is a best answer to the question of which data structure to use to solve a hypothetical problem. But in this case, almost certainly, you will be asked to elaborate and explain your answer.

Admitting you don't know is a better, more honest approach

"What should I say if I don't know the answer?" you might wonder. Interviews are designed to test you and you may be asked a question that you do not know how to answer. Trying to come up with a random answer is certainly the worst tactic. Remember, it is easy for an interviewer to tell if you are trying to cover up not knowing the answer to a question. This will also make a bad impression. Admitting you don't know is a better, more honest approach.

I value candidates that do this and generally give them some time to think. As an interviewer I realise that candidates are human, not machines, and I don't mind if someone doesn't know an answer but can still come up with a valid solution or explain their thinking process. When candidates demonstrate these traits it indicates to me that they can identify the end goal and how to tackle the problems leading up to a solution while utilising existing knowledge. This means that, as a colleague, they will have greater autonomy when working on their tasks in a work environment.

After the interview

• Don't contact the interviewers directly

Whether you think your interview went well or not, avoiding contacting the interviewers directly. As mentioned above, do not reach out directly to your interviewer via email or sending them connection requests, contacting them directly or following them on social media as this might be perceived as intrusive. This can lead them to think you are trying to get "extra marks" by doing so. After all, even if you are unsure about how you performed, the chances of you changing their opinion by sending them a direct message, are slim to none.

On the other hand, if it seems that the company is taking too long to get back to you, feel free to contact the HR representative.

• Failure does not mean you are not good enough

We have all experienced disappointment when we didn't get a job we really wanted. Job seeking is a very time intensive and energy consuming process and can feel daunting being in this position, but don't give up!

There are always multiple reasons of why your application was not advanced, and they don't necessarily relate to your skillset. There are cases that another candidate seemed like a more appropriate fit because of availability, location, or another factor.

The only way to find out is to contact back HR and ask for feedback. That said, don't expect to receive only positive feedback. Instead, use feedback as an opportunity to learn from any critique and don't take it personally. Your interviewers don't have anything personal against you. Use the feedback as opportunity to improve your performance for future interviews.

There are always multiple reasons of why your application was not advanced, and they don't necessarily relate to your skillset

• Practice makes perfect

Nailing an interview relies on multiple factors. Stress can derail an interview, even if the interviewer is trying to their best to keep you calm. The key is to practise again and again.

Thankfully, there are numerous resources you can use. For coding interviews, you need to understand how the compiler works, what is executed behind the scenes and how memory is managed. This applies even if you are working inside a managed memory environment (Java, C# or C++ with Unreal Engine). Try creating a memory pool in C/C++ or a system without using any external helper libraries.

You can also participate or watch mock online interviews sessions or assessment tools to sharpen up your skills. Some good online resources are CodingGame.com and Interviewing.io.

Final thoughts

I hope these insights will help to alleviate the pressure around interviewing and help you avoid potential mistakes. It may take some time until you feel fully confident during the interview, but each interview provides practice in navigating the process and provides you with a bit more experience.

Until you have secured your dream job, happy interviewing!