Hiring is a critically important matter that some companies take far too lightly. A company’s employees entirely determine its capabilities and output. The QA team can make the difference between buggy software that is hardly usable and a near-flawless masterwork. The engineers can make the codebase either an intuitive ease of adding features or a hopeless quagmire of tech debt where the simplest change can take endless hours of reworks. The producers can help tighten the focus on getting a clear goal so you are able to get in all the great features wanted. Designers make sure there is an overall vision that makes the product end up well executed (and fun, in the case of a game).

So, you better be giving a lot of thought to who you want to be on these teams. Being on both sides of engineering interviews, I’ve gleamed some idea of what works and what doesn’t. I’ve witnessed a number of interviews where employees came up with questions on the spot, sometimes not even knowing the answers themselves. This isn’t the best approach because they didn’t know the depth of possible answers or have good followups ready. When you are conducting an interview, you want a game plan. How should you approach giving the interview? Let’s first talk about what we would want to learn about a candidate when making this decision.

Joel Spolsky has a great article on interviewing that delves into this. We are looking for candidates that are going to be an effective employee and, according to Joel, this is basically someone who is smart and gets things done. That is an excellent general guideline, but I’m going to try and break this down a bit further.

What are the attributes we really care about when we say an engineer is smart and gets things done?

1. Makes good decisions when forming their code that result in a healthy and flexible codebase.
2. Quickly figures out the problems they debug and comes up with good solutions.
3. Is capable of accomplishing tasks needed for the project within a quick time-frame.
4. Is innovative / creative enough to come up with new ideas to improve the code and product.
5. Is aware of the user and actively attempts to provide a good experience for them.

This more or less covers the most important attributes we are looking for. So how do most companies go about doing these interviews? Well, the common industry convention for engineers is to interview with data structure questions, mostly algorithm-centric, and 3D math questions. Candidates are often asked to solve these kinds of problems on a whiteboard at some stage. Many companies present these questions online these days ahead of an in-person on something like Codility, HackerRank, or online whiteboard of some sort.

What does this test for? Well, it tests if candidates know specific algorithms / math steps off the top of their head or can otherwise quickly remember them. It shows they have studied these things. Which of the things above does this help find out? It kind of applies to 1 because you are more likely to make better structural decisions regarding algorithms because you know how they work. It sort of applies to 2 because you can come up with better solutions to algorithm bugs if you know how they ought to be working. But do most programmers mostly code these algorithms all day? Hmm. Not really. How many algorithms are there anyway? Do you know how they all work in general if you have good knowledge of some basic ones? Not exactly…

What about 3? Well, again, if you are creating algorithms then knowing them in advance lets you make them more quickly. Well, as long as you already know the exact algorithms you need… 4 or 5? It tells you pretty much nothing about those. You may be thinking it seems a bit odd that these questions are what is asked. Well, anyone who studies and knows this stuff has shown they have the wherewithal to figure it out and prepare well for the interview. This shows they have some intellect that will help them do well at the things you are looking for. There is definitely a correlation between people who can do well answering these questions and those who will be good employees. This style of interviewing works…sort of. Is there a better way? Of course.

We can test for what we care about in more direct ways that will get us a lot closer to what we want. That traditional algorithm-centric style is utilized mostly because it caught on as an interviewing fad with big tech companies as a not-so-nuanced way to test for proficiency in these niche areas that the companies deal with. Programmers became used to it and it spread to more and more companies. Guess who ends up interviewing programmers? Other programmers. They stick with what they are used to. They interview the way they were interviewed. A self-fulfilling prophecy. Testing this way isn’t necessarily wrong, but you could say it is a bit lazy. We should definitely try and do better. How do we do that?

Since most of the points relate to how they write code, having them write code is absolutely something you should do. But not on a whiteboard that creates a stressful environment while several people wait for them to produce immediate results. A lot of programmers work in different ways with different methodologies and workflows. Not all of these methods are conducive to quickly putting correct answers on a whiteboard. Why only test for a certain subset of qualified programmers and eliminate the rest? Many like to take some time, look things up to make extra sure they are implementing it in the best ways, and even test the code a few times with errors before getting it perfect. In fact, having programmers like that is often a boon over the types of programmers that immediately jot down some decent code.

Further, many companies are starting to recognize the stress that a short time limit puts on candidates and are finding ways to tweak the tests to accommodate certain individuals. Why bother with all that? What you really care about is that they have the best solution at the end of the day, so give them a day or two to complete it at home in one of the early stages. And don’t make it a brain teaser coding problem. You want something more grounded in reality. An actual project, albeit a short one, which allows them to show good code organization and thought. One company I worked at had candidates code the game of checkers. This can reveal tons of information about how they code and should only take a couple hours for them to complete. Or you can make up the rules for some unique game for them to code. Just don’t overdo it; no one likes the feeling of having to complete a 12-hour coding project just to get through the door of applying – although some companies do this.

There are many game studios who do a test like this, but it is far too often placed in the background and only briefly used for reference. I’ve seen candidates thrown out because they didn’t know the specific algorithm tested for during the onsite whiteboard session without a second glance given at their well-crafted code. Coding is what you are hiring them to do. Study their code. Have two or three programmers look at it as if they are doing a code review. Have them leave notes and discuss any issues seen. Hiring should be a group effort, so make sure the team is involved because the team is going to have to deal with their code if they get hired. During the onsite, pull up their program and ask questions about it. Learn how they think about code. Learn why they went with certain solutions. I have never once been asked about code structure in any programming work I was asked to do for an interview.

One common thing I’ve seen is that interviewers won’t even care how you wrote the code. They will look only at the solution method to see if you solved it in the most efficient way. Don’t fall into this trap. How someone approaches the problem is often more important than getting the most right answer. In fact, try to avoid programming problems with a single right answer to begin with because rarely is there one in a realistic scenario. I’ve been turned down in an interview with the reason that my approach of coding up a linked list data structure was inefficient because I could have put next pointers on the objects themselves to create a built-in linked list on them. But isn’t having a generic linked list data structure that allows a common implementation across the entire codebase where it needs it important? Using it may not be wise in some specific situations, but planning and organizing code can be more beneficial to a game than hyper-optimizing every system.

As an engineer, I know firsthand that the state of the codebase is very important. Programmers can, and often do, work against progress by not putting enough care into their code. Sure, they will still accomplish tasks and likely do more good than bad overall, but they leave more and more problems behind. Not immediate problems. The kind that lie in wait and creep up in a slow, menacing manner. The kind that slowly eat away at the code and surface at the worst possible moment when you realize you suddenly need a huge rework right before launch or the bugs come out only in retail. A QA team is a powerful tool, but they cannot catch everything. When hundreds of thousands of players start hitting the game, more problems always come out than QA will find. The best defense is a carefully crafted codebase. You’ll never be able to get all the bugs, but well-structured code can drastically lessen the amount of these post-launch issues.

One of the most important attributes to look for in an employee is motivation. Motivation touches on all of the points listed above. They will be more determined to make good decisions and accomplish tasks quickly for the good of the game. Even if an employee is smart and passionate about games, it doesn’t mean they will be passionate about working on them and actually improve the company processes and help shape a great one. Well, how do we go about finding out if they are passionate about working on games? Knowing if they have worked on some in their free time is a good indication, but I advise asking them. “Why do you want to work here?” This is usually a question given by HR, but they may not be looking for the exact same things in the answer. Sure, it’s a good culture fit if they love the work the studio has done and play their games every day, but why do they want to code the games? Is coding something they enjoy? Are they fascinated by creating things? Do they strive to write perfect code? There is a lot to be gained by asking this firsthand, yet I have never once been asked this by an engineer.

Engineers are generally focused on the engineering aspects of a candidate and often ignore this side of it, but this kind of information should be one of the most important factors of consideration for a lead choosing their team members. What else does their answer to this tell you? Well, if they say they just want a stable position and good pay – which some will – that’s fine. And if they are exceptionally talented technically, they may not be a bad hire. If they say they have some great ideas to improve your games and touch up some areas, I would rather take this person. Even if they have less technical experience, they will actively drive and push for the game’s success. They will make others more productive by asking things of them. This is invaluable. Vast amounts of technical knowledge is useful, but not everyone on the team needs to have this. You need both experience and motivation for a team to excel.

Critical thinking, planning, and organization outside of code is also quite important. You may initially think this is only needed for a lead since they will dictate tasks and do all this planning, but most great games are not formed by someone’s first thought about how to do something; they are formed through collaboration of team members working together. New systems should be discussed between the lead and multiple team members. If you have someone on the team who just phones out and does what he’s told, this is a loss for everyone. Getting things done on your own is valued highly in the tech industry, and while this is required at some point, it is not everything. Communication is important as well.

I have seen programmers spend a week on a task only to sit on it without submitting for months or even years because they don’t know how to quite work out certain kinks like a higher-up not quite understanding why the work is important or it being difficult to submit without disturbing the work of other teams. Plus you have to think about the future of the company; if you hire a bunch of people who don’t know how to manage anything, who is going to do it when leads leave the company? Some programmers come to work to code aimlessly, whether it has any benefit or not. You can get into a very bad spot if most people on your team are like this. Motivation comes into play here as well. Making sure your hires can organize things and push to actually get things going at all levels across the team will result in a very productive environment that can absolutely crush the speeds of an unmotivated team, even one working extraneous overtime.

None of this is to say you should never ask about algorithms or 3D math at all. If you are hiring a gameplay programmer that is going to be doing 3D math every day, it doesn’t hurt to verify they know how to do it. But even in this case, it’s probably more helpful to ask general questions about linear algebra to see if they understand it. Have a conversation with them about why the dot product can provide useful angles rather than asking if they know how to figure out if a ray intersects a triangle and to solve it within one minute – this is something they could just look up anyway. The bottom line is that there are plenty of uncommon ways to test candidates to get better results and tons of important things to evaluate. Are they good at debugging? Questions that address this are rare. Why not email them a sample code project with a bug in it and ask them to fix it before the interview? This is incredibly flexible because you can send them a real world problem of almost any caliber to test for any possible debugging skill you expect them to be capable of. A small time commitment up front to prepare this kind of thing can pay off greatly in the long run when shaping your team.

Paying attention and evaluating the human in front of you, how they code, how they think, and what their work ethic is can tell you much more than checking some boxes or making sure they know the answers to some specific questions.