Ask a Game Dev

The process for hiring a programmer is fairly standard, regardless of the programmer’s specialty (gameplay, graphics, network, engine, etc.). It usually goes something like this:

1. We get your resume somehow (either from your submission or a recruiter or something) and decide we think you have enough experience doing the work we need someone to do. Those who we think have sufficient experience get called back. Those who don’t do not. We usually only have enough interviewing/team bandwidth for so many candidates, so we typically pick who we think are the best of the batch and discard the rest. 

2. One of our recruiters/HR people calls you to see if you’re actually interested in the job and to ask a few basic questions - are you still looking for a job, your career goals, whether you’re willing to relocate, what kind of salary requirements you might have, etc. They’ll also answer your general questions about the job and working for the company if you have any. Not everybody wants to work for us - sometimes the job isn’t what they expected or they just have different career goals.

3. Assuming you want to move forward with the application, we usually then move on to the screening process. This is either a technical phone interview or a take-home programming test (sometimes timed) or both. The take-home test usually has some number of general programming and/or math questions and asks you to write some code. Our engineers will look over your test answers and judge them for correctness (whether your answer works), algorithmic complexity (whether your answer solves the problem quickly), and clarity (how easy it is to read and understand what your code is doing). 

The phone portion of this step is where you begin talking to actual devs who are on the team, typically senior or lead team members who are there to assess your skills. We usually ask two kinds of questions at this point - questions about things on your resume like why you made certain decisions and specific things you did, and short-answer technical questions to gauge your practical programming knowledge - data structures, algorithms, familiarity with concepts, and so on.

4. After passing the screening process, we move on to the face-to-face interview portion - typically the last step before we decide whether to extend a job offer. Usually this involves meeting with the team and the leadership. You will usually be asked technical questions but from more of an architectural perspective - to determine how you design systems and arrange data, rather than the smaller nitty gritty implementation details. This typically involves solving whiteboard problems while other engineers observe you and answer questions about the problem you might have. The problems here tend to be more open-ended in order to assess how you approach problems and think about them.

It’s worth noting that the testing process for (and therefore criteria for passing as) a junior programmer is much more forgiving than a mid-level or senior position. That is how we usually assess results - after everything is said and done, we estimate what experience level we think you are and whether we think you’re a good fit with the team. If you do well enough in step 4 to demonstrate you’ve got the skill set we expect and that you can communicate with our team, you usually get an informal job offer from the company within a day or two. This is where you get to negotiate things like salary, benefits, start date, etc. if you wish. If you tell us you’re interested, you’ll get a formalized offer letter to sign and return within 24-48 hours, and then you’ll start working for us on your start date.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Were I you, I'd do two things.

First, I'd take a sample of some code I've written for a project and post it to a programmer-specific website like Stack Overflow, asking for critiques and readability. As a programmer, your number one responsibility is to write functional code. Your number two responsibility is to write portable, legible code - if you want to get hired somewhere, you're going to be working on a team, and that means that other engineers are going to have to be able to look at your code and understand what it's doing. Imagine taking over a game system from somebody... say a camera system, or an animation system. The last thing you want is to spend hours trying to puzzle out what exactly the other person was doing. This is why legibility is usually more important than squeezing out that last bit of performance. If you're the only one who can understand it by looking at it, the code loses a lot of value if you ever leave or are unavailable. 

The second thing I would do is either visit the book store, or look online for programming tests and programming job interview questions. There are a lot of varying opinions on the necessity or usefulness of a programming test, but the only programming positions I've ever gotten that *didn't* require a programming test were ones where the job was already basically guaranteed to me because I had worked there before and they wanted me to return. You should be able to adequately complete both written tests and the verbal interview-type questions. One of the books I suggest is Programming Interviews Exposed. It's a decent primer on what interviewers will ask about basic programming concepts, and I've seen quite a few interview questions like the ones in the book. I've also personally used programmerinterview.com as a supplementary site, though the overall content isn't as good as the book I mentioned. Finally, if you are aiming for a gameplay position in specific (which is my expertise), you should understand and be able to explain what vectors, dot products, and cross products are, and why they are useful.

I'll be the first to say that not all software engineers are trained that way. One of the senior software engineers who helped create the animation system in Tomb Raider wasn't a computer science major at all, but a physics major. The main issue with being self-taught is that you don't necessarily get the 'why' while learning the 'how'. Concepts like data structures and the four core principles of object-oriented programming are important to know (the why as well as the what), and it's very easy to learn to code without picking these up properly. These are the two ways I would suggest using to test whether you're ready for an interview. Best of luck.