The Job Hunt: Design Tests
How to take them, how to make them, and what good they serve
There’s one last thing about the job hunting process for gaming that you should know about: the design test.
This will be a bit different from the other job hunt articles, because it’s written to be at least as useful to potential employers as it is to applicants.
See, I’ve taken dozens of design tests over the years. I’ve judged almost as many candidates based on their design tests. And I’ve even written a few design tests that were used at different studios.
And frankly, I hate most of them.
I think most places do design tests badly. I think design tests often waste the time of developers and applicants alike. And I think that design tests are only really useful in rare circumstances.
Mind you, sometimes I enjoy looking at a design test as a fun thought experiment. In my free time, I might write up an answer to a compelling design scenario. But I’m a design nerd like that, and I wouldn’t ask other people to do that kind of work for free.
So let’s take a look at design tests and try to solve their problems, huh?
Testing for testing’s sake
During the hiring process for a game studio, each discipline will take a different approach for testing an applicant’s relevant skills.
A programmer may have a technical skills test, where they’re asked to solve a specific technical challenge, often times while walking through their process in front of another programmer. While these aren’t strictly pass-fail tests (sloppy work makes a big difference in code!), programming generally has a clear threshold of “does your solution function?”, which softer-skill disciplines like art and design don’t always have.
An artist may have a portfolio review — a process that’s familiar to most working artists, where they bring the best samples of their finished work, and fellow artists look through the pieces and see if the applicant’s skills and processes fit with the style and quality level they expect. There’s a lot more room for “good skills but not what we’re looking for”, but at least a practiced artist has probably built up a large enough portfolio that they can highlight a few pieces that best fit the studio’s style.
A designer, on the other hand, gets stuck with the middle ground of the two. And a very time-consuming one, at that.
Most studios’ tests for designers falls into some version of the following:
“Here’s a theoretical game (or, sometimes, the studio’s most recently released game). Pitch a quest for this scenario. Then write a conversation between these two theoretical characters. Then write a pitch for a multiple-quest chain that this quest begins.”
(There’s variety between different types of designers: Level designers may be asked to build an actual full level for the scenario, combat designers may be asked to create enemies and enemy groups for the scenario, etc.)
As much as studios may claim otherwise, these tests can often require eight or more hours of work for a good designer, and often range into 10 pages or more. And unless the applicant already works at the studio, they may have little or no guidance about the studio’s preferred style for pitches or internal tools used at the studio.
This leads to a tremendous amount of work for any applicant, with little guidance — often before they even reach their third interview with the studio. This is a daunting task for any applicant, much less one who’s also performing a full-time job and has a family. And every designer involved in interviewing the candidate is going to have to spend their own work time reading the design tests of each and every applicant.
After all that, a design test is usually either accepted or rejected by the studio with little or no further reference to the work that’s gone into the test. It’s a huge waste of time for everyone involved.
Ideas are cheap
Now, I’ve seen some young designers who worry about submitting high quality design test entries, fearing that the studio might ‘steal their ideas’.
To them I would say: it’s understandable to be protective of something you’ve worked for many hours on, but don’t worry — what you’re submitting is, at best, a first draft of what would actually have to be built in game. Not only would stealing it be illegal (under the somewhat nebulous US labor laws), but it would be mostly pointless.
See, ideas and first drafts are the easiest part of game development. In 90% of cases, the quality of your idea means nothing compared to the skill of how you implement it.
That’s where the real day-to-day work of game development comes in.
So what’s a design test for?
A clever studio should be looking for how well an applicant has thought their idea through, how they’d handle building it, and (most importantly) how they’d handle revising it based on design feedback and unexpected limitations.
Yes, it’s important to see that an applicant has a good understanding of how to build a scenario for the player, how to communicate their plans to everyone involved in building different aspects of it, and general clear communication skills.
But that doesn’t require an applicant to make a custom creation each time they apply. All of this can be identified by seeing a candidate’s design portfolio or writing samples. A studio-assigned design test should only be necessary for entry or junior level applicants who haven’t already built up a decent design portfolio.
What’s more, a design test does nothing to test an applicant about how well they handle feedback, revisions, or build the things they propose, which is 80% of the work they’ll actually be doing.
How to make a good design test
Here are my own rules for making a good design test, or rather, making a design test experience that actually checks for an applicant’s real skills:
Step 0: If the applicant has an existing design portfolio, take a look at that. Don’t bother with a design test if you don’t need to. Between seeing examples of their work and talking to them, you should be able to identify the candidate’s skills without wasting everyone’s time.
Step 1: For candidates without a portfolio, have a simple, quick test they can take. It shouldn’t take longer than 4 hours to do. Keep it simple: one scenario/conversation/level/etc. Give them some example of the format you want. Base it on a decently-known game that’s already on your internal list of relevant benchmarks.
Step 2: Expect first-draft quality results. Do not expect a perfectly-formed final piece. Give a page limit if you have to. But try to avoid a time-limit — applicants have lives, and you’re not paying them for this time.
Step 3: Don’t reject a candidate based solely on the test submission (I mean, unless it’s wildly terrible or unprofessional). Instead, send it to everyone involved in the next round of interviews.
Step 4: When reviewing the test (or a sample from their design portfolio), make sure every peer or superior coming to the interview brings at least one piece of feedback for the quest to present the applicant. Even better yet, have someone from a different discipline come in with a hypothetical last-minute problem to present (“Oh, we had to cut that location — how would you change this to fit it into this other location, instead?”).
Step 5: Present these at the next interview and see how the designer responds to the feedback. Do they balk? Do they question the need for the changes? Do they know how to work with the other discipline to find a functional solution? Have them walk through their thinking so you can see their process.
I guarantee that the results of that post-test interview will give you a better sense for an applicant’s skills and how they’d work with your team than anything you’d see from a ten-page design test.
And it’ll cost less time for everyone involved.
When wasting time is the real test
When I was younger, I did a lot of ridiculously complex design tests. I’ve done tests that took over 30 hours of work. I’ve seen tests that required writing a full five-minute cutscene, along with pitching an entire questline and deep lore connections — all for a game that had only been publicly released two weeks earlier.
It’s a waste of an applicant’s time, but sometimes it’s more insidious than that.
For some studios, a big design test serves as a pre-hiring loyalty test — the studio is only interested in hiring people so dedicated to them that they’ll jump through flaming hoops for their approval.
These days, if I see a design test that I think is going to take more than eight hours of work, and a studio that’s not willing to look at a design portfolio instead, I’m likely to end the entire application process then and there. Not only is it disrespectful to the applicant, it’s a sign that the studio doesn’t know what they’re looking for, or that they’re looking for an applicant who’s easily plied into doing extra unpaid work.
Don’t work for studios like that. Don’t work for people who waste your time.
I love the idea of having employees from different departments that the applicant would be working with provide some of the questions. Good teambuilding move too.
:chef kiss: