Mint Banjo

Introduction

Over the past few years I’ve been to a few interviews for gameplay programmer roles in the games industry, so I thought I’d share a few ideas on what to expect and how to prepare.

What is a “gameplay programmer”? It’s a role you’ll find at larger studios, mostly working on code and logic for gameplay mechanics / gameplay loops, or general code to tie other game systems together. Smaller studios will tend to hire more generalist programmers who will work all other aspects of the game’s code. Common things a gameplay programmer might work on are:

• Input handling
• Game rules / game mode handling
• Player interactions with game objects
• Player inventories
• Missions / quests
• Vehicles / mounts
• Weapons / spells / damage handling
• Character code (jumping, special moves, etc)
• Camera

etc. To phrase it another way, it’s any code which is NOT one of these specialist programming roles:

• UI
• Physics
• AI
• Core engine code
• Core network code
• Tools programming
• Animation

(although they’ll certainly be expected to have a thorough understanding of these systems and utilise them, they probably won’t do much editing of them, though it varies across different studios)

This guide is tailored towards gameplay programming, but may apply to other code disciplines as well. It focuses on the interview process itself so I’m assuming you’ve already built a portfolio / CV / cover letter (lots of guides around the internet for those) and found & applied for a suitable role.

There are several layers of seniority for the role, in ascending order:

• Junior
• Mid-level
• Senior
• Lead / principal (roughly the same level of seniority but leads tend to focus more on team management / planning and principals focus more on the code)
• Tech director

Some of the concepts below may be overkill for junior level roles as it will be expected that you’ll learn them on the job.

Structure

Typically the entire interview process will include some or all of the following steps:

• Screening interview with HR / hiring team
  Mostly discussing your general job requirements (location, seniority, maybe a rough salary range), might touch on experience and reasons for job search, some more details about the role, etc.
• First interview
  Usually a fairly informal chat about your experience, education, games you’ve worked on, more information about the role, perhaps a few easy technical questions, etc (see below).
• Second interview / technical assessment
  A more rigorous assessment of technical skills, usually involves solving problems, writing code, and answering questions about the language / engine of choice, etc (see below).
• Third interview
  Might involve meeting and getting to know team members from a broader departments or other directors / studio heads. Could be a cultural fit check or an on-site studio visit.
• Offer, salary / benefits / contractual negotiations
  In my experience this typically happens via email and is fairly self-explanatory.

Some studios might condense it into fewer rounds than this, though I’ve always had at least the first and second interviews.

One piece of advice is to be patient: especially with bigger studios, it might be the order of weeks before you even get a response. Then it could be a week or so in between interview rounds. The whole process can last 1-2 months depending on the studio (though I’ve also experienced less than two weeks), so do plan ahead and factor this in deciding when to apply. Though this delay can be slightly annoying from your perspective, just remember they’ll be likely processing and interviewing many other candidates, and the people interviewing you also are trying to make games at the same time!

Below I’ll go into a bit more detail about the more important of these steps.

First interview

This will likely be a chat with 1-3 employees of the studio, probably including a tech director, a lead programmer, or a studio head / member of the production team. The format is usually a ~1 hour discussion / panel interview. It will probably be online via MS teams / skype / zoom etc.

Some general advice is just to be yourself, be personable, enthusiastic and friendly. Always try to phrase things in a positive manner: never bad-mouth your current company or co-workers, or come across overly negative or arrogant. Try to be relaxed, as these are usually quite informal. Read the job description thoroughly and try to sneak in demonstrating that you satisfy as many of those requirements as possible.

These are some common questions you might be asked, I’d definitely recommend having an answer prepared for most of these or at least have some idea about what you’d say.

• “Talk through your experience in the industry so far”
  Should be easy enough. Might also touch on how & why you got into the industry in the first place etc. Try and sneak in some enthusiasm and how you like playing / making games, working in a collaborative environment, etc. Talk about the projects in detail and the tools you used.
• “What are some of your strengths / weaknesses”
  Seems to be becoming less common as a question. For the weaknesses, be honest but pick something that isn’t devastatingly crippling to your chances, i.e. can easily be worked on, and mention some ways you’ve improved it lately.
• “Why are you looking to leave your current company” / “Why do you want to work here”
  Almost always asked. Obviously the answer should be phrased positively and reflect well on yourself. Try not to say anything negative about your current company, instead flip it and state the positives you’re looking for in the new company. It’s great to also reference specific things about the role or studio in question, e.g. “I was impressed by game Y which your studio made” or “I want to work with X engine / genre more”. In my opinion, honest logistical reasons are also fine, e.g. “I want to relocate” or “I want to work remotely”, providing the job description accomodates that. (Personally, I would not mention salary here, but that discussion is outside the scope of this article).
• “Talk about your side projects”
• “What are some gameplay features you worked on in your last role” /
  “What’s the code feature you’re most proud of in your role on game X”
  I’d recommend refreshing your memory pre-interview with some notes about what features you worked on previously. They’ll probably follow up with some details like how you structured the code, how you solved X problem, etc. I sometimes have a video prepared from a youtube “let’s play” or trailer etc for games you’ve worked on, and you can offer to show a mechanic via sharing your screen, which helps with the explanation and breaks up the monotony of talking.
• “Talk about an instance where you overcame some technical difficulties”
• “What kind of games do you like to play”
  Always seems to come up towards the end, any answer is fine here as we’re all gamers who like playing games! If possible you can try to focus the answer towards games from a similar genre to the one you’ll potentially be working on (if you know it). You can also try to mention about a certain game mechanic you enjoyed etc, or maybe even discuss how you think it was implemented.
• “Do you enjoy mentoring” / “have you done any mentoring” (of junior programmers)
  Typically asked for non-junior roles, where most people from mid-senior upwards are expected to help with the progression of juniors on the team. They’re also trying to guage whether you work well with other people and are happy to help your colleagues if they ask for it. They might ask for specific instances of when you helped a colleague fix X problem etc.
• “Talk about an instance where you worked collarobatively with designers / artists / etc to improve a feature”
  Another check on whether you work well with others, try to have some examples prepared.
• “Talk about a time you’ve fixed a particularly hard bug / optimised a certain piece of code”
  Gameplay programming isn’t always about building new features, it does involve debugging and optimisation, so be prepared for this.
• Technical questions
  These generally will be from a high level and depend on the project you’ll be working on. They usually won’t grill you in too much detail (which is reserved for the second interview).
  For example they might ask about your experience with a certain engine, how you enjoyed working with it overall, general questions about its structure (e.g. does it use an entity component system, a more inheritance based approach, etc).
  They might ask about your knowledge of a certain language (C++ / C#), your thoughts about feature X of that language, what you might change about the language, etc. Rarely they’ll throw in a few detailed quiz-style questions about a language.
  If the role involves a lot of multithreading or networking, they might ask high level questions about those paradigms, or to provide examples of where you’ve used them previously.
  They may ask about your experience with source control and other tools, or your experience with other specialised code areas like UI, AI, animation etc.

Towards the end you’ll have the chance to ask some questions yourself. Think of some interesting questions you want to know about the role as this part is also about you interviewing them. To be honest, if a candidate couldn’t think of anything to ask here, it would probably reflect poorly on them, showing a lack of curiosity or interest in the role. Ask stuff like the size of the team or structure of the team, if they follow best practices in terms of code reviews / documentation etc, how do programmers work with designers (are there design docs, or is it more iterative), what kind of features you’ll get to work on, the production processes, etc.

You can ask specifics about the project, including genre / shipping platforms / planned release date etc, but be prepared they might not want to share too many details at this point, especially if the game is unannounced. Other studios might make you sign an NDA pre-interview so they’ll be free to talk about the project more.

Tech assessment

Format

This part will be a much more detailed deep-dive into your technical knowledge, almost certainly with some testing or coding involved.

Some general advice here is to over-prepare if possible, as it’s quite hard to know exactly what will come up (it varies a LOT across studios). There are lots of books (such as the excellent “Cracking the coding interview”) and blogs covering these topics, so read up if possible. Try to thoroughly and carefully read the requirements before diving in and don’t be afraid to clarify. Take your time and analyse any code line by line. If you get stuck, don’t panic and try to think logically, as a last resort you can ask them for help getting started.

Importantly, don’t forget that you may not be expected to get every question 100% correct – you are not being measured against the material, but against how other candidates handle that material.

The format will usually involve one or more senior or lead programmers, testing your knowledge for 1-2 hours. It can be online or on-site. You might be asked to remote into a dev environment to do some actual coding, use your own coding environment whilst sharing your screen, or use an online coding tool, or answer verbal questions, or use a whiteboard. The style of questioning varies a lot and might involve some combination of the following (more on how to prepare further below, with more examples):

• Leetcode / codility style questions
  Usually using some kind of online portal, it will phrase an algorithmic-style question, with a window for you to write your answer, with some auto-testing functionality.
• Algorithmic / data structure questions
  They might ask you to implement a common algorithm or data structure, and then talk about the code and choices you made. Might be game-related such as some vector math or intersection tests etc.
• Fix or review this buggy program
  They might have some basic program such as an implementation of a basic algorithm or data structure, with some common programming errors, and you have to fix the program or do a code review of it. (Be on the look out for stuff like assignment instead of boolean comparison, off-by-one array access, nullptr access, memory leaks, variables in the wrong scope, uninitialized variables, etc).
• Implement this game feature
  They might have an unfinished basic game like pong or space invaders and ask you to implement a certain feature (like ball collision, damage etc).
• Verbal questions
  A deep dive of quiz-style questions into your language and/or engine of choice. May also cover vector math, data structures, or walking through how you’d solve a certain problem etc.

There is also the much rarer “take-home” style questions where you’ll have 24 hours to complete some assignment in your own time; but I’ve only ever seen this once, and most companies explicitly said they don’t do it.

Preparation

Here’s a list of things to study or revise in preparation for the interview.

Data structures

Practice by implementing your own simple versions of the following data structures:

• Dynamic array
• Binary tree
• Linked list
• Stack
• Queue
• Graph
• Hashmap

Ideally templated / generic, with common interface functions and memory management. This gives excellent practice using and testing them, and common operations like traversing a graph breadth-first and depth-first, removing a linked list node, searching a binary search tree, memory allocations, etc.

Be aware of the pros and cons of each structure and when it’s best to use them (space and time complexity of common operations).

Algorithms

Practice implementing a few common algorithms, identifying big O time complexity, and optimising. Some may have already been covered in the above data structures, underlining their importance. There are also plenty of resources on the web to find further problems (e.g. https://www.geeksforgeeks.org/top-10-algorithms-in-interview-questions/, https://leetcode.com/.

There are seemingly endless problems on websites like leetcode, some of which are far too hard for a short interview so probably won’t come up – in my experience they’ll want to test you on a few medium problems rather than one hard problem. But it’s worth tackling at least a few in order to grasp some core concepts. Once you’ve done this, you’ll start to get the hang of finding strategies for optimal solutions (such as: use a sliding window method; use a hash map; use a binary search), and being thorough in your code for catching edge conditions, etc.

Some general algorithms I found helpful:

• Finding prime numbers
  Practice the naive implementation to find prime numbers up to N, and the more advanced Sieve of Eratosthenes . There are some common optimisations (e.g. only looping up to the square root of N).
• Sorting algorithms
  Practice implementing a few easier ones, such as bubble sort and selection sort. I would also try merge sort, which is probably too hard for a short interview (it can be surprisingly tricky to implement), but it’s worth doing as it’s a pretty cool algorithm and also involves the sub-step of merging two sorted arrays which is quite a common algorithm. Know the O runtimes of each (best case, average case, worst case) and tradeoffs.
• Binary search
  A good example of logarithmic runtime
• Find all permutations of a string
  A good example of a recursive algorithm
• Reversing a linked list, swapping a pair in a linked list
  A good examples of pointer manipulation
• In-place rotation of an NxN matrix
  Just a fun little algorithm which can be surprisingly tricky and helps with a few concepts (see for example https://leetcode.com/problems/rotate-image/)
• Container with most water
  https://www.code-recipe.com/post/container-with-most-water – a pretty clever application of a simple algorithm with an easy brute force solution and O(N) optimisation.
• Longest substring without repeating characters
  A good example of using a hashmap / sliding window to optimise a solution. See the explanation on leetcode: https://leetcode.com/problems/longest-substring-without-repeating-characters/solutions/127839/longest-substring-without-repeating-characters/

Mathematics

Nobody is expecting gameplay programmers to be experts in advanced math, but the fact is you will use some kind of maths on an almost daily basis so you will probably be tested on it. If you’re looking for a good primer I would recommend the book “3D math primer for graphics and game development”. I would make sure you know the following:

• Basic vector maths
  Understanding what a vector is, the difference between a vector and a scalar, vector length / normalising, obtaining the vector between two points, etc
• Dot product
  How to calculate it, what it logically represents, how it can be used (this page is quite helpful https://www.falstad.com/dotproduct/)
• Cross product
  How to calculate it, what it logically represents, how it can be used
• Coordinate spaces
  Transforming between local and object space, nested coordinate spaces, etc.
• Rotations
  Be familiar with the three main ways of storing 3D rotations (euler angles, matrices, quaternions), and how they are represented in code and their trade-offs (gimbal lock, space complexity etc). It is not vital to know the full details of how quaternion / matrix operations are implemented, but you should probably know the rough idea, and how to use them (e.g. quaternion multiplication, inverse, etc).
• Interpolation
  Linear interpolation, spherical interpolation using quaternions, linear mapping from one range to another, etc.
• Calculus
  Know the basics of numerical integration, differentiation, and the relationship between time, velocity, position and acceleration. Bonus points for stuff like forces, momentum, kinematics.
• Geometry
  Brush up on basics of circles, spheres, ellipses, quadrilaterals, triangles, planes (formulae, areas, circumferance, sin and cosine, etc)
• Intersection tests
  Common examples which come up are line-line intersection, line-sphere intersection, box-box intersection, circle-circle intersection, line-plane intersection, line-box intersection, etc.

Language

You’ll be expected to be an expert in the language used in the project. The most common language in the industry is C++ (used by cryengine, unreal engine, and most in-house engines), followed by C# (used by unity). I’m mostly a C++ dev so the following applies more to that.

• Keywords
  Know what all keywords in the language are and how to use them
• Inheritance
  What inheritance is, why it’s helpful (polymorphism), abstract base classes / interfaces, common pitfalls (e.g. virtual destructors, diamond problem)
• Pointers and references
• Smart pointers & dynamic memory
  New / delete, shared pointers, unique pointers, weak pointers; when to use each of them
• Casting
• Constructors (different types)
  Default constructor, synthesised constructors, copy / copy-assignment, explicit keyword, destructors
• Move semantics
  R-value references, move constructors, move-assignment constructors, optimisation using move semantics
• Const correctness
• Operator overloading
• Templates / generic programming

Other concepts

A few other important concepts to be familiar with: whilst they probably won’t come in a coding test, they’re a crucial part of the job so general questions may be asked:

• Multithreading
  Be familiar with all aspects of working on many threads concurrently; thread safety, the difference between background and foreground threads, race conditions, mutexes, etc.
• Networking / replication
  Only relevant for multiplayer games, gameplay programmers are responsible for using APIs to make sure their features work over the network. It’s worth brushing up on the API for your chosen engine, as well as core concepts like dedicated servers / listen servers, authority, controlling when / how often replication happens, remote functions, etc.
• Cache efficiency
  Whilst gameplay programmers probably won’t need to know exactly how CPUs work on the harware level, it’s worth knowing in general terms how CPU caches work, and how to program to avoid frequent cache misses which can affect frame cost in games.

Conclusion

That about wraps it up! Though it might seem a lot, in my opinion it’s best to over-prepare, as gameplay programmer is quite a popular role and competition will be fierce. Sometimes it seems like actually landing the interview is the harder challenge, and you only get one chance to make a first impression, so it’s best to make it count! Finally, if you end up studying all this stuff and only a fraction gets used at interview, the worst case is that you’ll have made yourself a better programmer 🙂