Job Interview Tests

tim-cain hiring interviews game-design programming level-design industry

Abstract

Problem: Why do game studios use in-person interview tests, and what do they actually look for?

Approach: Tim Cain draws on decades of hiring experience to explain the reasoning behind interview tests, shares specific example questions for programmers and designers, and addresses common complaints.

Findings: Interview tests exist primarily because candidates frequently lie or inflate their contributions. The tests aren't about right answers — they're about observing thought process, attitude, analytical ability, and how candidates handle critique of their own preferences. At-home tests fail because candidates look things up or get outside help.

Key insight: The purpose of interview tests is not to find the "correct" answer but to observe how a candidate thinks, communicates, and handles ambiguity — skills that directly predict how they'll function on a team.

Source: https://www.youtube.com/watch?v=1WxB2c02_Js

1. Why Interview Tests Exist

People lie. Tim states this bluntly as the primary reason. He's had candidates claim knowledge of C++, STL, and pixel shaders they didn't actually possess. The most common form of dishonesty is inflating one's role in shipped features — claiming integral involvement or sole ownership of work that was collaborative.

Beyond catching lies, Tim wants to observe candidates in action: their thought process, communication style, and attitude. Game development is collaborative — no one works in isolation sliding code under a door. He needs to see how people work, not just what they claim to know.

2. Why Not At-Home Tests?

Many candidates request take-home tests instead. Tim identifies two problems:

  • Candidates hate them too, viewing them as unpaid labor (potentially days of work)
  • People look things up online or get help from friends, defeating the purpose

The fundamental challenge remains: how do you verify it was actually the candidate's work?

3. Programming Questions

Tim asks general programming questions himself, leaving specialist topics (graphics pipelines, pixel shaders) to lead programmers in those areas. His standard questions:

3.1. The Deceptively Simple Ones

  • Given an integer, return true if even, false if odd. Programmers think it's trivial. Tim implies edge cases make it less so.
  • Given two integers, return their average. Again seems easy, but integer overflow and odd sums create pitfalls.
  • Implement atoi or itoa. Convert a string to a number, or a number to a string — reimplementing standard library functions.

3.2. The String Reversal Chain

Tim's favorite, because it allows progressive follow-ups:

  1. Reverse a string — basic implementation
  2. Variation A: Now do it without extra memory
  3. Variation B: Reverse the words in a string ("how are you" → "you are how")
  4. Variation C: Reverse the words without extra memory

If the candidate handles an advanced variation naturally in their first attempt, Tim notes it positively and skips ahead.

3.3. The Behavioral Question

"What is the most difficult piece of code you ever had to implement, and why?" Tim pays more attention to how they answer than what they answer — looking at behavior and attitude.

4. Design Questions

Design is broad, so Tim breaks his questions into categories. He leaves narrative design to narrative leads.

4.1. General Design

  • Top three games of all time — why they're your favorites, and critically: the best and worst feature of each. If you can't identify a flaw in your favorite games, that's a red flag. Repeat for your least favorite game — can you identify what it did well despite disliking it? This tests the ability to evaluate objectively without emotional bias, a skill essential when working on your own game.

  • Three favorite game genres — there's no wrong answer, but how you answer matters. Dismissive responses ("I don't like action games so I won't tell you the other two") or unusual preferences (microtransaction-heavy games as a top genre) lead to interesting follow-ups.

  • Design an RPG without classes — what are the advantages and disadvantages of a class-free system versus a class-based one? Tests whether designers understand why they make design choices.

4.2. Combat Design

  • Create a numerical weapon ranking system — what factors determine how "good" a weapon is?
  • Determine hit probability — what factors go into whether a weapon hits a target, and why?

4.3. Level Design

  • What makes a good combat environment? What would you do as a level designer to make combat fun? Name a game that does this well.
  • Race-specific starting zones — what are the pros and cons of having different starting areas based on player character race?

4.4. Economy Design

  • Gold per hour — how would you determine the rate players receive gold? What factors matter (player level, zone, etc.)?
  • Adding high-level items without obsoleting existing ones — how do you introduce new powerful items to a live RPG without making current items worthless?

5. The Playlist Question

Tim shares a favorite non-game design question he uses as a pure critical thinking exercise:

You're designing a music playlist editor. Users can add songs anytime. What should happen when they add a duplicate?

Four possible solutions:

  • A: Silently refuse the duplicate
  • B: Silently add the duplicate
  • C: Show a popup asking whether to duplicate
  • D: Let the user set a preference at playlist creation (duplicates allowed or not)

There's no right answer. Tim wants to hear the candidate's reasoning and watch them evaluate each approach.

6. What Tim Is Really Looking For

Across all these questions, the common thread is not correctness but process:

  • Thought process — how do you reason through ambiguity?
  • Analytical ability — can you evaluate things you love critically, and things you hate fairly?
  • Self-awareness — do you understand why you make design choices?
  • Attitude and behavior — how do you handle being challenged or asked to consider alternatives?
  • Relevance — if you're interviewing at an MMO studio, have you at least researched what they make?

Tim acknowledges these tests aren't perfect and invites better alternatives — but any replacement must answer three questions: Does the candidate actually know what they claim? Did they do the work themselves? Can they work well on a team?

7. References