Lazy Foo' Productions

Interviewing for Game Programming

Last Updated: Feb 14th, 2022

So you’ve managed to complete your computer science degree. You go to your school’s resume workshop to polish your resume and you start sending out applications. Then months later, you still get no callbacks. Why?

Because you screwed up badly by starting your job applications process after you graduated.
Caution: Probable typos ahead.

The strategy of blindly sending out resumes hoping one of them will bounce back (known as the spray and pray strategy) is the most common and one of the most ineffective ways to get a game programming job. To properly prepare for applying for game industry job, it takes months if you’re really lucky but it will most likely take years. Waiting until senior year to start your game programming studies is way too late.

In this article I will be covering what you need to know to get ready to apply for a game programming job. This is based off my personal and the experience of my immediate peers, so do take it with a grain of salt. If you want to be a game artist, designer, producer, etc that will be a different path with different requirements so take this article with a massive mound of salt.

Get Your Skills Up

As an undergrad, you should be spending at least (as in a minimum) 40 hours of week programming. Your classes count towards this time. This includes summer/winter/vacations. Summer doesn’t mean game backlog time, it’s personal project time.

For your freshman/sophomore year, you need to clear that first hurdle of getting something made with C++ and a low level API like SDL. You want to make sure to take a C++ course as early as you can in your academic career. I recommend keeping the scope limited to something like Tetris. Don’t be afraid to do a couple of stepping stone projects like Tic Tac Toe or Blackjack before diving into Tetris. You may be tempted to make something like 16bit era platformer for your first project, but everybody’s first few projects are giant heaps of spaghetti code that you will want to abandon. Your first projects should be about getting your hands dirty with the fundamentals of game programming.

In your sophomore/junior year, you should have completed your Tetris clone and be disgusted with how much of a crime against software engineering it is. Good job, many don’t get this far. Your next project will be a little meatier. Here is where you may want to take on a 16bit era or 2.5D style platformer. Maybe you’ll even take a stab at making something 3D but simple like an early 3D era game like Quake. By now you should have completed linear algebra and physics (also take these as soon as you can) and this would be a good time to apply those skills. This would also be a good time to get acquainted with an engine like Unity/Unreal so you can get used to their design patterns. Either way, a good rule of thumb is to keep this project with a hard 1 year time limit. This project will also likely be a giant heap of spaghetti code and time spent trying to go back and fix your mistakes would be more useful if you just started a new project having learned from your mistakes.

For your junior/senior year, there are two projects you want to get finished: your capstone game and your tech demo. Your capstone is a human ready game (meaning it should ready to present to people who aren’t programmers) that you want to be the game your potential employers will see. You should have gotten your hands plenty dirty with your Tetris project and your 1 year time boxed project, so hopefully by now you know to keep scope limited so you can make everything nice and polished. What you want this project to say is that you know what it takes to make a shippable game even if it’s small. If you can work with a team that also looks good, but make sure you work with people who are decently experienced and also have worked on year long game projects.

The tech demo on the other hand is for programmers. As you were making your games, you got to touch on various things like graphics engines, physics engines, artificial intelligence, maybe even a little online multiplayer programming. The tech demo doesn’t need to be pretty, but it should show that you have a deeper technical understanding of how a certain component of a game works. It could be something like a hand rolled graphics engine, a hand rolled physics engine, a from scratch C++ game engine, a set of AI demos, remaking one of your old projects with a multiplayer online component and match making, etc. What you want this project to say is that you have deep understanding of a specific domain of game programming.

If you’re not sure what to make (and even if you know what to make), I recommend following the conventional marketing wisdom of reasoning backwards and starting from what the market wants. Google game studios nearby (“Los Angeles game studios”, “San Francisco Game Jobs”, etc) and see what they’re looking for. Get a good sized sample and gear it towards what they’re looking for. Try to balance it vs what you want to do. If some place is looking for graphics programmers but you hate doing performance analysis, you’re better off doing something you’re more interested in.

A Note About Unity

Before I continue, I want to explicitly state that I don’t hate Unity. If I were to open my own game studio, there’s a decent chance I would use it myself. People like to bash Unity, and I have been stuck in the studio past midnight dealing with Unity issues, but every game engine has its issues. It’s a perfectly fine engine that has its ups and downs like any other engine.

However, a major problem with game engineers I have interviewed is that they are completely dependent on Unity. It is a red flag if I look at your portfolio and all I see is Unity projects. I do highly recommend having at least one Unity project in your portfolio (along with an Unreal project) because there is a high demand for Unity skills, but I also need to see that you know how to operate with lower level C++. It is possible to be overly dependent on Unreal Engine, but I have noticed engine dependency is more of an issue with Unity/C# game developers. If you end up working for a studio and they get handed a project that uses legacy code or some sort of hand rolled engine, they need to know that you won’t be completely lost without Unity and C#.

Prepare for Your Interview Questions

A very common interview question is “What have you been reading lately?”. I always carry a book on me because as a games engineer you’re always expected to stay current.

What books should you read? I generally refrain from giving book recommendations because 1) learning how to research is more important than me spoon feeding you’re a list of books to read and 2) I already get enough e-mails from people wanting me to promote their book and I don’t want to encourage that.

But I will give you a list of subjects you should be familiar with:
  • The basics of graphics programming. Not everybody needs to be a Vulkan expert (that’s usually only for the graphics/engine specialists), but I would expect a game programmer to know the basics of vertex data, texturing, lighting, shadows, shaders, and image post processing even if it just OpenGL 2.1.
  • Physics engine design. You should know how to at a conceptual level how a rigid body simulator is made. You probably don’t need to know things like fluid simulation unless you’re a specialist.
  • Game engine architecture. Game engines are like operating systems and it’s important to know why they are designed the way they are.
  • Advanced C++. I can nearly guarantee that your undergrad C++ course is not enough. Know what it takes to be effective with C++ and how to deal with C++ when you’re trying to squeeze every ounce of performance. Also learn how C++’s unmanaged nature can lead to security issues.
  • Video game AI. It is different from the AI they typically teach in school. You probably won’t need to know machine learning (unless you’re a specialist), but you should know the basics of how to make bots for a player to play against.
  • Multiplayer network programming. Almost every big title has an online component to it and you should be familiar with the fundamentals of latency compensation.
  • Software Engineering Fundamentals. You should know development processes even if they are not specific to game development. Know things like common searching/sorting algorithms, version control, design patterns, CI/CD, agile, etc.
  • Backend development. With online games come things like match making. You don’t have to be an expert, but you should know at a conceptual level how to make a REST API.
  • Advanced databases. Again, your undergrad is probably not enough here. You should know about databases that aren’t just SQL databases and how having to deal with hundreds of thousands of concurrent users affects database deployments.
  • Cloud infrastructure and Service Oriented Architecture. It’s OK if you aren’t an expert in AWS and Kubernetes, but you should know what they are and what they do.
  • Software security. With online game come hackers and you should know the basics of how to deal with them.
  • I am assuming you are going to an accredited computer science program that teaches the fundamentals of algorithm anaylsis, classical mechanics, linear algebra, computer architecture, databases, network programming and operating system architecture. It is technically possible to get a game programming job without a degree, but you cannot afford to have any gaps in your knowledge.
How well should you know these things? Here are some real sample interview questions I have either received or given in interviews:
  • Explain how vertex data gets rasterized into pixels. For the sake of simplicity, let’s assume it’s a flat shaded mesh.
  • Explain how shadow mapping for a directional light works.
  • What’s the difference between forward and deferred rendering?
  • Explain how skeletal animation and skinning works.
  • What are the major differences between OpenGL/Direct3D11 and Vulkan/Direct3D12/Metal?
  • Explain how collision detection between two convex polygons works.
  • A gun fires a ray at a collision mesh, how would you tell where it hits a mesh? How would you optimize the collision detection?
  • Explain coarse/fine collision detection.
  • What is a contact? Explain a method of processing contacts.
  • Explain the differences between using Euler angles, rotation matrices, and quaternions for representing object orientation.
  • How can inline functions make code faster? How can it show it down?
  • Optimize this code without altering the contents of the functions:
    void someFunctionA()
    	while( somefunctionC() )
    		Pretend there's a whole bunch of code here
    void someFunctionB()
    	Pretend there's a whole bunch of code here
    bool someFunctionC()
    	Pretend there's a whole bunch of code here
    	return someCondition;
  • What are the costs of inheritance/polymorphism?
  • How are floating points represented in binary?
  • What is the deadly diamond?
  • If you C malloc memory then C++ delete it or C++ new memory and C free it, what happens?
  • What can happen if you do not bound your array copies? (Hint: it’s bad. Real bad)
  • How would you use a profiler to optimize code that is running slow?
  • Explain how a behavior tree works.
  • Explain how a blackboard works.
  • Explain how a nav mesh works.
  • Explain the fundamentals of the Tribes networking model.
  • Explain the fundamentals of rollback latency compensation.
  • Explain how TCP maintains in order communication of data.
  • What is a REST call?
  • Name two wire formats and the advantages/disadvantages between them.
  • What is vertical and horizontal scalability?
  • What is an Enterprise Service Bus?
  • What is a reverse proxy?
  • Explain the basics of public/private key cryptography
  • Name two different types of No SQL databases and what are the advantages/disadvantages between those and a SQL database.
  • What is virtualization, containerization, and orchestration and how would you use them in deploying a match making service?
  • You have a fresh AWS account (or Google Cloud Services/Azure), what infrastructure would you need to set up for an online pong game with around 50,000 daily active users?
  • What is a service level objective and a service level agreement?
  • How would you implement an anti cheat in a racing game?
  • How would you secure a match making API?
Keep in mind, these are not questions only for a lead or even software senior level games engineer. These are all questions I have seen for entry/mid level game engineering positions.

Being a “Google Dumb” Software Engineer

Story time: Do you know where I got the name Lazy Foo’? When I was coming up with a name for my website, I was originally going to call it “Lazy Programmer Productions”. I changed it to Lazy Foo’ because programmers use “FooBar” all the time when naming things and I wanted to keep to the theme. As to why I called myself lazy, this was back during my freshman year college when I was stuck in my “I’m lazy but smart” phase.

Here’s the thing: there’s no such thing as “lazy but smart”. In reality, I was lazy but unchallenged. When I got out of college I was outperforming nearly all of my colleagues in my graduating class. I had shipped a contract work game, made a physics simulator for my senior thesis, and was rolling my own graphics engine when most of graduating class couldn’t make anything more complicated than Tetris.

When it came to filling out applications, interviewing, and landing a position this meant nothing. There’s a concept of being “Google Dumb”. Google only hires 5% of the engineers they interview. For the sake of comparison, Harvard admits 6% of the applicants. This means you could be better than 90% of the people Google interviews and you still wouldn’t be as good as the worst person working at Google. You could be in the better than 97% of the people who interview, but you’re still in the bottom half of Google engineers.

Now I don’t want to get bogged down in the semantics on whether the interviewing process accurately measures the quality of candidates and whether one is smarter than the other. The point I am trying to make here is that just because you are strong relative to your academic peers that does not mean much when you are going to be when compared to other professional level applicants.

When I was involved in the interviewing process at a fairly no name studio, we still got over 100 applications for a single opening. Of the hundred that applied, we only seriously considered about 2 or 3 for the position. This is nothing compared to big name studios that can easily get over 1000 applications for a single position. To work for a studio that made fairly basic mobile apps (not big name AAA projects), you had to be in the top 3-5% to be considered.

Even tiny game studios are picky because they can afford to be. It leads to funny situations where I was being asked advanced computer architecture questions when I ended up doing basic UI programming that any decent programmer could do once I actually got the job.

Don’t make the too common mistake I see with students who think they’ll be able to waltz into a game studio and get a job offer. Being the big fish in the small pond of your school means nothing when you’re going to have to be swimming with sharks in the industry.

Filling the Gaps in Your Knowledge

A decent amount of you might be panicking after reading that list of game programming interview questions. Well, it’s better that you freak out now rather than getting hit with them during an actual interview like a deer in the headlights. Rather than coming at you with a list of books to read, I am going to show you how to research.

Now a lot of you may be tempted to go Google the answers to the questions above. I recommend against this. Any decent place will be using the questions above a spring board to conceptual questions that don’t have correct answers to test how deep your knowledge is. If all you did was Google the answer the questions above, it will become very obvious.

My advice is to instead of looking up the individual questions is to look up the concepts. Keep researching until you can answer the questions above. Instead of Googling “forward and deferred rendering”, look up “beginner friendly graphics programming book” or “best graphics programming books”, etc. Sift through reviews, look through the previews, ask on forums for recommendations, look up tutorials to get primers, and just get used to looking for gaps in your knowledge and finding ways to fill them in. You’re better off Googling “game physics books”, getting a collection of resources to give yourself a deep understanding as opposed to just Googling “how to check collision between two polygons”. I do recommend until after making your first little Tetris clone before spending any money on books. Most books that are worth money are at the professional level and they won’t be very useful until you’ve gotten your hands dirty.

A good way to search for gaps in your knowledge is to keep browsing GDC talks. There are a lot of them free on YouTube. If there’s anything in a talk that you are completely lost about, that probably means there’s a gap in your knowledge that you need to fill. It’s ok if you don’t know PBR front to back if you’re not a graphics specialist, but you should have a general idea of what it is.

Two books I will specifically recommend are The Algorithm Design Manual and Cracking the Coding Interview. They aren’t game programming books, but they do cover the fundamentals of programming pretty well. I have worked at studios where the interviewer will take someone in, tell them to whiteboard merge sort and if they can’t they’ll send them home early. Make sure to get your general programming fundamentals down along with your game programming.

Getting Your Resume Ready

You may be asking “Wasn’t this article supposed to be about the interview process?”. Well you’re going to need a decent amount of projects completed and a decent amount of research done to reasonably expect to make it through an interview. Now that you have some decent projects done and knocked back several hundred pages of research (I still to this day do thousands of pages of research years into my career), it’s time to get your resume ready.

By now you should have a list of places you’re looking to apply in your area. If you don’t live in a major game development hub like Los Angeles, research other cities. Fortunately work from home is much more widely supported than it used to, but there are still companies where they want people to work locally. I do recommend landing a job before moving because I have seen too many people move to expensive places like San Francisco to chase their dreams and walk away with nothing but empty bank accounts.

First get your resume ready. There tons of guides out there on how to prep a resume that can prepare you, so I’ll stick to a couple of overall guiding principles:
  • There is no reason for your resume to be more than one page long. I’ve known people with two decades experience that are able to keep their resume to one page. There’s no reason a fresh grad can’t do it either. If you legitimately have more than a page of content, just start cutting the least important things.
  • Say as much as you can with as little as possible. Open with a summary that is a roughly tweet sized TLDR of what you’re about (remember, they’re going to be looking at over a hundred resumes), followed by the most important things professional experience, academics, and then personal projects. Entering competitions, hack-a-thons, and volunteer work also look good on a resume. If over the course of your career you resume grows to over a page, start condensing the less important sections. My personal projects section went from 75% of my resume after my first job to a few lines of things I worked on the side.
  • Make sure it looks professional. I have seen too many resumes with cutesy graphics and quirky junk like “level 99 C++ programmer”. Assuming that 99 is out of a 100, I would expect a level 99 programmer to be able to write an optimized C++ compiler. A good rule of thumb is to not think you’re applying to a game studio, but to a bank. Game programmers don’t play video games all day, we have stuff to do.
  • If you have any links to projects, make sure they work on any major platforms (Windows, MacOS, iOS, Android). I recommend creating a video reel of the projects alongside any github links in the case you made a Direct3D graphics engine and they want to see it on their phone. Remember that people are going to be reluctant to download executables from strangers.
  • Don’t just list words, tell us specifically what you did with them. Don’t just put “Vulkan” or “Vulkan Graphics Engine”. Put “Made Vulkan graphics engine that supports rigged meshes, X antialiasing methods, Y post processing effects, Z lighting/shadowing, and has been tested on these platforms” etc.
I recommend also Googling around for existing professionals and using their resumes as a benchmark. But before you do, let’s talk about professionalism.

Being Professional

I can’t believe I have to say this, but don’t be invasive. I have had friends who got jobs at big name studios only to have some… let’s say overly enthusiastic people start repeatedly e-mailing them after they found their website begging them to get a job at the big name studio. This is a really fast way to make sure your resume will be thrown out.

A big part of your career will be networking and attending networking events. I have lost track of how many stories I’ve heard of people knocking back one too many and waking up the next day with a hangover and an e-mail telling them to pick up the box with their stuff outside of the studio.

Even if you are at a industry party with dance music playing, you’re still at a professional setting. If you make a fool out of yourself there, they will remember when you send in your application. Whenever you interact with someone in the industry, act as though they are interviewing you because there is a decent change they will be interviewing you or know someone who will.

Resume Keyword Stuffing

There’s one thing about resumes that gets asked a lot: “Should I put this on my resume?”

The answer is: Probably yes, but be prepared to defend it.

There was a resume that went viral on the internet. It was part of an experiment where a developer submitted their real resume and compared the results to submitted a fake resume that was completely nonsensical but stuffed with buzzwords (seriously, look at this thing):
seriously, look at this thing
The buzzword laden trainwreck got interview offers from big name companies where to real one got nothing. Do not assume a human familiar with software development will read your resume before the company will reach out to you for an interview.

You may take this as a necessity to fill your resume with buzzwords regardless of whether you even know what they are, but I recommend against that. Never lie on your resume and avoid bending the truth as much as you can. If you apply at a place and not do so well, they may consider you again in the future. Lie on your resume/application they definitely will not call you back.

If you need to optimize for buzzwords, find a minimum viable project to build something with the buzzword. For example, if a place you’re applying to is looking for someone who is experienced with Unity and Android, find a tutorial to get Android working with Unity, make a basic Fruit Ninja type game work on Android, and then you can put “Ported a game to Android” on your resume.

Granted, if they are looking for a Unity Android specialist this will not be close to enough. However, a lot of the time when companies post requirements they’re more a wish list than actual requirements. They may not need someone who can debug release only bugs on Android, but someone who can build and run on the game on an Android device. At least it’ll get you past the resume screening which often time is at best done by a recruiter who does not know the difference between C, C++, C#, and Objective-C or at worst is done by a bot. And you did with without lying, just by doing a minimal project that would allow you to put that on your resume.

As always though, anything you put on your resume you need to be prepared to defend. Just as you are honest and didn’t put any egregious exaggerations you’ll be fine. Just don’t push your luck.

Cleaning Up Your Portfolio

So your resume is nice and spiffy and now it’s time to send them a link to your projects. One of the biggest mistakes fresh grads do is send them a link to their git repos without making it presentable first.

When looking at a portfolio, you again have to remember that your portfolio is one of dozens. They have stuff to get done on top of interviewing, and they’re only going to give you a minute at the most. They are looking for any excuse to thin out the pile of applications and if the first thing they see is your hello world project from freshman year of college, they probably will not scroll down to your awesome physics engine.

Design your portfolio with a 30 second hook that will make them want to see more. I recommend creating a professional looking website with a professional name (not something silly like Lazy Foo’ Productions). Minimize friction as much as you can. If you made an iPhone game, put screenshots and videos if they are browsing from a PC. Only put your best projects. They will likely only look at one, maybe two or three if you grab their interest. They will want to look at code so make sure that is easy to find and browse. If you do grab their interest, you can put additional stuff like more projects, competitions you entered, an extended version of your resume, etc.

Oh and I forgot to mention, you should have professional experience before applying to your first game industry job.

Getting Professional Experience

You’re probably asking how can you get a job in the industry if you need to get a job in the industry before you get a job in the industry. When it comes to game programming internships, I have repeatedly heard from recruiters that they only give those to students from top ranked schools. Does this mean you have no chance of getting into the industry if you don’t go to some super expensive school?

No, because it does not need to game programming professional experience to help you. In terms of the order if jobs you should look for:
  1. Get game programming experience if you can. If you don’t go to a top school, probably the only way you’re going to get a position is if you are connected. Networking is important, people.
  2. Get something that uses game industry tools. There are companies that use things like Unity, Unreal, OpenGL, Vulkan, DirectX, or C++ for movie effects or simulations programs. Getting a job making a real time 3D world is an excellent springboard to game programming.
  3. Get a job that uses C++. Because schools are moving towards languages like python, low level programmers are increasingly rare and therefore valuable.
  4. Get a job in mobile programming. The mobile market is a huge part of the gaming industry to say the least. Experience in this field is very valuable, especially if it’s with low level Objective C or Android native programming.
  5. Get a job using C#. This is a good springboard to get into Unity positions.
  6. Get a job as a backend/DevOps/build/etc engineer. Games need these positions, too.
  7. If you can’t get any of the above, take what you can. Any sort of development experience looks good on a resume.
This isn’t a hard order of what you should look for, but the rule of thumb is the closer it is to game programming, the more valuable it is.

I have been part of the hiring process for both game and non-game developers. Where tiny game studios still get 100+ applications and can be super picky, I have seen non-game studio hire people who can barely write freshman level programs and hire them hoping they can get them up to speed because they’re still the best out of a dozen candidates.

So if you can’t afford to go to an expensive game development school, a stepping stone company will help out a lot because we will care more about professional experience and your portfolio.

Some of you may be asking if it is possible to get a job in the gaming industry without a degree. I have seen it happen, but it is fairly uncommon. Outside of the gaming industry, programmers without computer science degrees are not rare by any stretch. The problem is is that recruiters get massive stacks of resumes are they are looking for any excuse to thin the stack and throwing out anyone without a degree is one their favorite methods make the stack smaller. It is possible to do it without, but I would definitely recommend getting a degree from an accredited computer science program.

If You Still Can’t Get Into a Stepping Stone Company

So because of your school schedule or whatever other reason you can’t get any programming jobs. Lucky for you, we’re in the mobile age and you can always self publish.

Make a game for the Apple AppStore or Google Play store (or both if you can). If you don’t like mobile development, you can make a desktop application. Again, keep it simple because the most important thing is that this thing ships. Getting a match 3 game out the door is better than an unfinished full 3D game. One of the hard lessons indie developers learn is that conceptually simple games can be very time consuming to polish into a market ready game. I guarantee you it takes much longer than you expect and this lesson is much easier to stomach with a match 3 game than with something more ambitious.

With an ad SDK, you can even make some money off of it. If it makes money, you can say you have professional experience as a self employed game programmer.

Sending Out Applications

Ok, so you researched positions in your area, you got your polished and professional portfolio with your capstone project and technical demo, you have your stack of books that you’ve read, you’ve been working on practicing your programming problems, your resume is nice and polished, and you got your professional experience as your ace in the hole. You’re ready to send out applications.

You’re probably are not going to be hearing anything back for a while. For one, back when I was fresh out of college only 1 out of 10 or so places were hiring fresh out of school game programmers (this is my personal experience, not a hard statistic). This means that if you live in a place with 200 game companies, there are only about a dozen positions for new game programmers. The other reason is that the application process just takes a while. I’d would send out applications for a month and not hear anything for like 6 weeks and then suddenly I’d get a flood of replies.

Even if you’re a senior level engineer, it can take a few weeks for them to reply, it can take a few weeks for a few rounds of interviews, and then once you’re selected it can take a few weeks for all your hiring paper work to go through. Don’t be surprised that even under the best of circumstances it can take 2 or 3 months between sending the application and your first day of work.

Another reason is that I was looking for work at an odd time. As you approach the winter, interviews tend to slow down because people don’t want to deal with a new hire as they approach the holidays. The beginning of the year also tends be slow for hiring until the end of the first quarter when the new fiscal year starts. This can be problematic because if there is a 6 month gap between when you graduate and when you’re applying, it can be a red flag.

There are people who graduate in the fall and end up firing up applications right in the middle of a hiring drought. It can happen where somebody starts looking for work in January, things don’t pick up until March, they don’t get anything by the end of June, and they’re stuck with the fact that they don’t have a job 6 months after graduating which makes it even harder to get a job. This is why as you’re applying, don’t stop working on your portfolio. I recommend spending 50% of your time on applications, 50% on beefing up your portfolio and researching. If you have an extended unemployment gap in your resume, they’re going to ask you what you have been doing in that time. Make sure you have a good answer.

Finally, a Reply

So they like your resume and portfolio and they let you know that they want to start the interview process. Every company does its interview process differently, but the generally have the same overall structure. It usually goes:
  1. A phone screen
  2. A test
  3. Live interview
Some companies do a test before a phone screen. Some only do a phone screen and then a live interview. Some do multiple tests, some do multiple live interviews, some even just send you a project and will hire you if you complete it. The order and number of phases varies, but they tend to have similar phases.

Typically, they open with a phone screen. This is where they get to know you, walk through your resume/portfolio, and to ask you some fundamental questions to see if you’re the right fit for the job. This is where your knowledge of general algorithms will get tested along if you have been doing your research. My biggest piece of advice is not to get cocky. You can ace the phone screen and get nuked in the live interview. The phone screen is just to filter out people who are not remotely qualified. They’ll ask you questions like what is the time complexity of iterating to a linked list, and other questions you’ll be shocked they even need to ask. There are quite a few people who lie on their resume, and this phone screen is mostly to eliminate the people for whom it would be a waste of time to do a full interview of.

Don’t be afraid to ask questions of your own. Ask them about what software management methodologies they use (it will most likely be agile), how many people will be on your team if you get hired, is the project they are working on funded already, what do they do to manage code quality (like code reviews), and how they avoid crunch. Anybody with a basic understanding of software project management knows that crunch causes productivity drops in a matter of weeks. If they’re dodgy about anything, it’s a sign that they are probably run by bad managers.

Then a lot of the time they give you some sort of test. They may send you some questions, or a link to some automated testing program. These questions will be a bit beefier than the phone screen questions. Where the phone screen is to filter people are not even the ballpark of qualified, the test is there to check whether you have to decent chance of qualifying for the position. Again, don’t get cocky if you ace this too because the real interview is coming soon. These tests tend to have specific answers (there’s only so many variations on quick sort), the live interview are more conceptual, broad, and are about your ability to solve complex problems that don’t have specific right answers.

The live interview is often multiple interviews one right after the other. Back in the day, these were always in person but with work becoming increasingly remote don’t be surprised if it’s a series of zoom calls. Each interview covers different domains like gameplay, math/physics, algorithms, computer/engine architecture, network programming, backend/cloud, etc. At any decent studio, they will care more about your problem solving skills than your ability to memorize. Don’t be afraid to ask questions. It’s ok if you forget trivial things like the name of the function that adds elements to a C++ vector. The fact is they will care more about how you arrive at the answer than what your answer is.

If they like you, in a few days they will hopefully get back to you. I know I said that of 100 applicants only 3 or 5 are considered, but this is how the applicants break down based off my personal experience:
  • About 50% have nothing outside of school done. These resumes get thrown into the trash.
  • Another 20% have a side project but it’s not related to gaming. These also go in the trash.
  • Another 10% have a single Unity game project. They go into the maybe pile but are almost certainly going to eventually be thrown out.
  • Another 10% have a bunch of Unity projects. They get to the phone screen and maybe the test, but usually end up bombing the questions on low level programming.
  • Another 5% have some Unity and Unreal Projects along with tech demos showing their understanding of low level programming. They slip up portions of the live interview. They have a chance of getting hired if everyone else takes another offer.
  • The last 5% have good game projects, a good tech demo(s), and have a super solid understanding of low level game programming. One of these will end up taking the job and 2 or 3 of them will have multiple studios offering them positions.
While probably only the top 5% are going to be considered for being hired, the fact is the vast majority of applicants range from awful to mediocre. I’ve talked to a lot of students that wanted to get into the game industry and the ones who don’t make it don’t make it less because they are not smart enough, but more because they don’t want to put in the work to build their portfolio, have a strong understanding of low level programming, and properly market themselves.

I Got The Job! I Made it!

Uh, no.

I hate to be a party pooper, but it’s super important that you don’t get complacent. For one, I have known multiple people who accepted an offer only to have the project they were supposed to work on or the studio itself shutdown shortly after being hired. I have personally done a phone screen and then found out the studio was going to shut down the day after. Only 1% of games are profitable by at least 1 dollar and, no, I didn’t eyeball that statistic. If a company has 10% of their games be profitable, they’re doing 10 times better than the industry average. AAA games that rake in millions are anomalies. The project you are working on is most likely going to fail. Game studios drop like flies and you need to be able to make it through the process again because you are likely to have to do again in the near future. Do not be surprised if your first job does not last you a year. The first two years of your career are especially precarious because recruiters typically look for at least two year of experience.

Part of the reason the students who I tell need to keep their low level skills sharp don’t listen to me is because they know a guy who got in the industry without learning all that. The guy they know is the type who thinks just because they got a contract job before all their friends did that they’re the second coming of John Carmack. They’re also the type who ends up stuck taking the same entry level contract positions years into their career where the friends worked hard on low level programming are now leading teams.

Yes, you can get a job in the industry without knowing how vtables can affect performance or how to architect a match making service that can scale, but your employment quality in terms how stable your job is, how well it pays, and how well they treat you is not going to be as good as someone who does.

Still to this day I am researching despite being years into my career. Why? Because as you get further into your career the interviews get harder. When companies look for someone with five years experience, they expect someone who has also been working on side projects and researching for 5 years. There are people who fall out of the industry because after five years they don’t make it past the more advanced interviews and nobody will hire them for entry level positions because they can get fresh grads who will take lower salaries.

One more thing that can help your employability is specialization. Being well rounded helps a lot early in your career because smaller studios are the ones that tend to take in more fresh grads and they need engineers who can wear multiple hats. Bigger studios on the other hand can afford to hire multiple people that are each super good at one specific area of development as opposed to a bunch of people who are competent in many different areas. In demand specialists get paid the best and have the most job security.

Be careful about pigeon holing. Say for example you took a backend programming job as a stepping stone to your game programming job. You want be a game play programmer, but since you’re experience in backend programming they put you on backend programming tasks. Before you know it, you have spent years doing backend programming and they won’t put you gameplay programming tasks because they need your backend expertise. This is where side projects will help your break out of your pigeon hole.

And Now for Some Sodium Chloride

With the exception of the fact that around 1% of games makes make a dollar of profit or more, the percentages I mention here are based off me eyeballing my personal experience and me consulting with a handful of my friends. They aren’t statistics based off a random representative sample. They’re based off my personal anecdotal experience.

The game industry is not a monolith. For example, for the most part I’ve heard that nobody cares about objectives on a resume. However, I am also heard there are people who do care. I have personally encountered multiple game programming interviews where they asked about backend programming and cloud infrastructure, but I know people who worked at studios who don’t ask those questions to the game programmers unless it’s specifically a backend position. I can tell you I have personally tanked an interview at a big name studio because I was completely unfamiliar with backend programming at the time.

When I set out to write this article, I decided to write the article I wish read before starting out. I have never interviewed at Activision or Microsoft, so maybe it won’t help you getting a job there. However, I can say that had I read this article when I started out, it would have allowed me to ace all the interviews I have encountered. This isn’t the ultimate games engineering interview guide (I haven’t even covered specializations because I am not a specialist in everything), but it would have helped me out a lot and hopefully it will help you too.

So don’t take this guide as gospel and try to get as much input as you can. Do be careful who you take advice from, especially if they’re not senior level. There are so many entry level games engineers who are convinced they can do no wrong. I look at their portfolio, see their Unity platformer and I ask them what else they got. A Unity platformer is not a bad thing to have in a portfolio as a capstone project, but for every open position I get like two dozen Unity platformers so you need something else to set yourself apart. This of course offends them that I dared question their abilities, then I ask them some standard game engine architecture interview questions which they tank and then they accuse me of being elitist. Their big fish in a small pond syndrome wouldn’t be a problem if it wasn’t for the fact that they then convince their classmates that they also can lower their standards.

Nobody is a programming god, even if they work at a big name studio working on a big name project. I once worked at a studio where they interviewed someone with nearly a decade working at a AAA studio working on big name projects who could not iterate through a linked list. This is far from the only time I have heard big name studios hire people who weren’t the best. This can easily happen where someone gets an entry level position, but does nothing but entry level work for years until they get laid off. Being well connected can get you pretty far even if your skills aren’t up to par.

There’s a saying “The more I learn the less I know”. This is true because with every bit of research I do, I find another rabbit hole I could go down. Being a professional game programmer is like climbing an infinitely tall mountain. You’re only going to like it here if you enjoy the climb and you’re not looking to reach a peak. For this reason, you should always side eye anyone who tells you to lower your standards.

Oh No, I Graduated and I Have Nothing! Am I Toast?

So you’re a few months out from graduation with no side projects and no research completed. Can you course correct? Yes. Will it be easy? No. Will it take long? Months, if not years.

At this point you have to main options: get a job in gaming QA or get another software engineering job. There’s no shame in slogging through QA to get a games engineering job. Most game engineers do. The path is still the same, get your C++ Tetris clone done, get your capstone project done, get your tech demo done, do your technical research, and studying interview questions. When there’s an opening, apply and ask for a recommendation. Companies tend to prefer to hire internally. As I have said many times before, don’t get complacent or you may have to take QA position again. Another option is getting a non games engineer job. Get a job as close a game programming position as you can. Build your portfolio and practice those interview problems. The engineering job will probably pay better, but it will likely be easier to jump from a game QA position than a position outside of the industry.

You may have messed up, but you can recover if you put the work in.

Wow This Looks Hard

The games engineer life is not for everyone. I have people asking me if they should become games engineers. To that I reply if you genuinely have to ask, the answer is you shouldn’t.

Layoffs are always around the corner because the vast majority of game projects make no money. At any point you can lose your job and even in the best of circumstances this can mean 2-3 months with no paycheck which translates to thousands of dollars of income lost. This is why one of your first goals as a career game programmer is to save 3-6 months of expenses to tank any incoming layoffs. This is on top of the fact that games engineering positions don’t pay as well as positions like full stack development. Don’t even get me started on the unpaid overtime. There’s a reason the average game programmer career only lasts for about 5 years. Remember, average means half last less than that.

For those of you who are just born to be game programmers, I hope this article better prepares you for the rough seas of the gaming industry. Good luck and happy climbing.
If you have any suggestions to improve this article, it would be great if you contacted me so I can improve this article. Back to Index