Any technology which is distinguishable from magic is insufficiently advanced.

Job Interviews for Game Programmers

Posted: January 24th, 2016 | Author: | Filed under: Soapbox, Tutorials | No Comments »

Wow, 2 years without a post. Time sure flies when you’re having fun! Since I happen to know that a lot of my friends and former students are currently partaking in the great job hunt, I figured I’d write on this, given the large number of interviews I’ve ended up conducting over the years.

The most important thing to realize in interviews is that time is precious. During this time, the interviewer has to find out as much about you as possible and figure out where you might best serve the company. There is an objective behind every single question asked, no matter how trivial or complex. They do not expect you to be able to answer every question flawlessly, but instead seek a better understanding of your personality, aptitude and experience based on how you tackle the problem. So do not panic if it seems you are drowning in the unknown. Just breathe in and embrace the liquid mayhem.

There are 4 basic qualities that I personally look out for in interviewees. They are not the guidelines dictated by any specific company, but have slowly evolved in my head over time. These are them in order of importance.


It is vitally important that you are able to express your ideas clearly, and understand what is being conveyed to you. If you do not speak the native language of the company well enough to be understood, that is a blocker.

More than that, the way you speak reflects upon the way you think, regardless of any language impediments you might have. A good interviewee would speak clearly, concisely and to the point. A bad one will ramble on, beating around the bush before eventually (or sometimes not at all) getting there. This is not a high school test where if you hit the right keyword, you get the marks because it is in the marking scheme.

Often, I will ask a deliberately vague question to see if the interviewee will clarify the problem parameters, and if not, which direction they go in and what assumptions they make.


One of the main tasks of the interviewer is to figure out what level you are at, how valuable you would be as an employee (i.e. how much they should pay you), and whether you would be suitable for a lead role. From simply talking with many people, I’ve come to recognize that there are certain basic qualities that allow easy categorization regardless of discipline (i.e. this works for artists, producers, etc. as well). As much as people try to over-represent themselves during interviews (from either ego or deceit), these are aspects that simply cannot be falsified. Job experience and academic achievements do not factor into this assessment.

Non-starters are people with basically zero aptitude. They fail due-diligence questions like “What is a dot product?” or “Describe inheritance in OOP.” I have encountered Masters graduates who could not write a single coherent line of code. Sad day.

Juniors have a good grasp of the concepts and are eventually able to solve problems. They will often fail to consider edge-cases and do not necessarily grasp the implications of the smallest of their decisions, at least until it is pointed out to them. However, good juniors are humble, eager to learn and are reasonably good at solving puzzles.

Mid-level engineers are insufferable because they know just enough to be dangerous. Their hallmark is over-thinking and over-engineering. They will often have elaborate and complicated designs to circumvent pitfalls they encountered in the past while opening up a dozen more. They look for “tricks” in the interview questions and try to pre-empt them, often fouling up the basic answer in the process. They almost always think they are much better than they actually are, not necessarily through hubris, but because they haven’t yet developed an appreciation of the breadth of things they are unaware they don’t know. They write know-it-all articles, much like this one.

Seniors are hard to find. They have developed a consistent internal framework through which they can solve the majority of problems they have not encountered before. They have a holistic sense of the game development process and are empathetic to how their choices affect the project, and how solutions and/or compromises can come from other disciplines. Their solutions may seem magical or out-of-the-box to others when in fact, they simply have a bigger and better organized box. When they encounter problems they have no immediate answer for, they get excited because it is a learning opportunity and a chance to expand their box even more.


Most companies are looking to fill a gap. We need somebody to do X and X and X. The larger the company, the more specialized this would be. This is because the added depth adds a lot more value to the company than just another generic programmer would. If interviewing a graphics programmer, I would expect him/her to write better shaders than I can, and maybe I can pick up a thing or two from them during the interview if I am lucky.

Smaller companies prefer general programmers because they can tackle many different tasks and generally solve the problem with a satisfactory result. They are the most cost-efficient way to get the game out of the door. This is what results in the difference in quality (and budget) between indie games and those coming out of the mega-corps.

Sometimes during the course of the interview, it will become apparent that your current skills do not match the niche they are trying to fill. At this point, it is a good idea to point this out and declare yourself unsuitable for this particular role. It would spare the interviewer the awkwardness of figuring out how to break it to you gently, and displays a maturity and clarity that will bear you in good stead when a position that does fit you opens up.


Cynics define passion as a direct measure of how little a company can get away with paying you to do the most amount of work. This is not incorrect. In the end, it all comes down to business. In a creative industry like game development, a heavily-self-motivated employee will be a thousand times more productive than somebody who’s just doing a job. Also, they would be less likely to leave at the first sign of green pastures, particularly in the middle of a project.

However, passion is much more than that. Why do you want that particular job in that particular company as opposed to anywhere else? What should the company do to keep you happy? What can the company do to make you deliriously ecstatic? If your answer is “More Money!”, I would recommend a job in the financial sector. Game development is not for you. Otherwise, being clear and truthful about what the company wants out of you, and what you want out of the company will make the relationship infinitely simpler and easier to manage.


The interview process is a two-way street. Both parties are trying to find out if there is a way for them to reasonably work together. Over-representing yourself is a common mistake as it murkifies the communication. (Besides, we know when you’re naughty!) I believe that for interviews at least, being honest and upfront (within the constraints of any NDAs) is the best policy. You don’t just want a job. You want a job that will make you happy, and will make your future employer happy to have you.

Here are some common interview questions. Can you tell which qualities they are trying to measure? (hint: it’s often more than one)

  • Why do you want to join our company?
  • Describe your proudest achievement to date.
  • What’s the biggest challenge you’ve encountered so far in your career? How did you overcome it?
  • What games do you play? What do you like about them?
  • What is your opinion of overtime work?
  • Please write some code that does this ridiculously simple task. What trade-offs did you make? How can you improve it?
  • What’s the difference between a vertex shader and a pixel shader?
  • You need to transport a dog, a cat and a mouse across a river. You can only carry one animal with you in your kayak at a time. You can’t leave the dog alone with the cat. You can’t leave the cat alone with the mouse. If you put the cat in the kayak more than twice, it will scratch your eyes out. What’s the minimum number of trips you need to make to get everybody over to the other side?
  • How would you deal with an unreasonable supervisor making stupid (in your opinion) decisions?
  • Have you any experience with Shaders? How about multithreading? Pathfinding? Networking? Physics? UI? Anything? Anything at all?
  • On a scale of 0 to 9, rate your C++

Leave a Reply