At the Office

Home

On the Couch

At the Office

In the Library

Through the Mirror

Mailbox

Neighborhood

The Game Designer Interview Exercise

The question of how to get a job as a game designer is a perennial one. Designer is one of the "sexy" jobs in game development, particularly as the common misconception of it is that you get to sit around and think up game ideas all day. While I've covered the basics of getting a job as a designer elsewhere, I thought I'd walk through one of the exercises I use when interviewing designers to give a more in-depth view of the specific kinds of things potential employers may be looking for. This is something that I've developed and refined over several years, and while not foolproof, it has been remarkably successful in separating out the wheat from the chaff at the phone interview stage.

Generally, I start a phone screen with basics - background, interests, work history - to establish a conversational tone and a level of comfort with the candidate. Assuming we don't hit a break point (radical mismatch between the job and the candidate's skills and experience, inability to communicate effectively, etc.), I then move on to the exercise. It starts with asking the candidate to identify their top 5 best-designed games of the last few years. There's generally some hemming and hawing here, but eventually we get a set of 5. The next step (don't worry, I'll go into more detail on how all this works below) is to focus in on one of those games and ask the candidate to justify in detail why it's one of the best-designed games of the last few years. This will generally produce several gameplay topics, which I then go in-depth on, asking the candidate to analyze specific dynamics and mechanics and come up with changes that would improve the game. By the end of this, I know both what kind of a designer I'm dealing with and how skilled they are. I can then narrow in on specific issues related to the job role I'm hiring for and get more information about their level of experience and suitability.

The Breakdown

Step 1: The List
First, it's very important to define that the list is the "best-designed" games, not the "best" games. You could spend hours debating what makes something the best, and I don't really care about things like sales or reviews, what I want to know is what the candidate identifies as being crucial to good design. Even though this list is just the starting point, it actually can convey a lot of information. For example, if the candidate identifies all games that are on a particular platform (handheld, PC, console), that may indicate a lack of range in experience; it's a yellow flag that gets marked for further follow-up questions. Similarly, if the candidate's list is full of games of one genre, if they're all older games, if they're all quirky/niche games, if they're all recent blockbusters, any of these patterns can be symptoms of different kinds of bias or weakness. Ultimately, though, the real purpose of the list is to establish a common ground. I haven't played every game out there, and for interview purposes, I want to be able to get into details on specific game design topics, but it never fails that at least one out of the five games that gets mentioned is something I know in-depth, so that becomes the basis for our case study.

Step 2: The Case Study
Once I've identified a game that we both know in detail, I'll ask the candidate to justify why it's one of the five best-designed games of recent years. There are two keys to this question. The first is that the way the candidate positions the game tells me a lot about how they understand design. There are no flat-out wrong answers here. It's more like a personality test. If someone starts with how well balanced and paced the game is, I know they're a systems designer. If they start with the look and feel, I know they're an experience-driven designer. If they start with specific moments, I know they're a content designer. Story, execution, concept, there are lots of different flavors here. The second key is how well the candidate can establish an argument. All design positions require strong communication skills, and this gives me an opportunity to see not just how articulate they are about game design (how sophisticated their vocabulary is, how many aspects of game design they touch on, how deep they go), but also how much mastery of rhetoric they have. Designers have to not just be able to describe games but also to convince people that one approach is better than another, so how compelling the argument is can provide good insights into these types of skills.

One of the subtle aspects of this question is that it forces candidates to focus on what works rather than what doesn't. Criticism is more than just being critical; it's easy to point out the faults with a game because they stand out. Mechanics that cause frustration, bugs, faults in execution, these things naturally announce themselves during a play experience. Being able to identify what works is harder, but also more important for designers. Simply avoiding the mistakes of other games isn't enough to make a compelling experience; you need to know what makes an experience compelling and how to accomplish that.

Some of the common issues that get marked for follow-up in this stage of the exercise are things like focusing on overly broad concepts (fun, pretty, addictive) without backing that up in detail; focusing on dynamics that are peripheral to the main experience in the game; focusing on non-design aspects (performance, art, sales); characterizing systems as well-designed that I personally didn't find that way (one of the reasons why it's important to use a case study we both know in detail); and generally focusing on the player experience rather than the structure of the game that informs that experience. These aren't make-or-break issues, but they're definitely things I want to follow up on.

Finally, this discussion also inevitably brings up a variety of in-game experiences. Just as the list provides a common ground for the case study, the case study identifies areas on which we can do the drill-down.

Step 3: The Drill-Down
Based on the previous discussion, I'll take a specific area of the game, something like character controls, or AI, or combat mechanics something we can really get into detail on, and I'll ask them to explain why that particular system or aspect of the game works so well. What I'm trying to get at here is how deep they can go, whether they understand just the mechanic or also the actual implementation behind it. We'll generally cover several different specific topics as part of this discussion, until I get to something I feel they have a good, thorough grasp on. Mind you, not being able to find one is a major red flag. Assuming we do find one, though, then I'll ask them how to change that system to make it better. This is really the heart of the matter, the real minefield.

The specifics are important here. There are a lot of bad answers, changes that would actually not improve the gameplay, changes that would be costly to implement, changes that would adversely impact on other systems. In addition, how the candidate discusses this is important. Do they take into account how this would be implemented? Do they account for changes in other systems to complement this change? Do they consider the learning curve, how it would be staged in content? Do they discuss getting buy-in from other team members, taking it around for input? Do they specifically address the cost and possible trade-offs? Going through several of these detailed systems will generally get me a deep assessment of which areas of gameplay the candidate has expertise on and where the weak spots (or blind spots) lie.

The other two things I've found useful to throw in here are "what aspect of the game could you cut to make the game better" and "what system would you add to make the game better". Again, the approach is really what's important here, although the specifics matter. How the candidate relates these systems to the rest of the game's design is what's really telling, and it's as much about the justification as the individual system. This can also generate an opportunity to have someone sketch in a system design, although that's generally better suited to an in-person interview.

Step 4: The Mop-Up
This is where I go back and re-visit all the issues that have been flagged. Some people get nervous during an interview and miss points that they would normally catch, so this is a good chance to make sure that the issue is really one of expertise and not simply trying to keep things concise. This is also an important stage to bring up any aspects of design that the candidate didn't touch on, to test for how well-rounded they are.

After all of that, I generally have a sense of what type of designer I'm talking to, where their strengths and weaknesses lie, and what kinds of process they've developed. There's a lot more to an interview than just this exercise, but I've found that it's an invaluable tool for being able to get a relatively complete picture of someone's skills in less than an hour, over the phone. Hopefully it will be useful to other hiring managers out there, and for those of you looking for a design job, you might want to make sure that you're prepared for something like this.

Back to top

Home

On the Couch

At the Office

In the Library

Through the Mirror

Mailbox

Neighborhood