Tagged in: job

From Student to Designer: Part 6 – Entry Level Design Jobs

As usual, my advice is specific to design and to seeking a more traditional job in AAA development, as opposed to breaking in as an indie, but most of it can be applied elsewhere. And as always, this is just my personal advice!

Part 1: Websites & Resumes
Part 2: Portfolios
Part 3: Cover Letters
Part 4: Design Tests
Part 5: Interviews
> Part 6: Entry Level Design Jobs

There is a myth that there is no such thing as an entry-level position in design.

It really is a myth, and a hard one – it seems – to dispel. I run into this idea from aspiring designers and industry people alike and it always kind of stumps me. Back in the day (not really that long ago), I was a student , and I got an entry-level job on graduation. A bunch of other students with me did too. And I’ve since worked with a bunch of people that went straight from being students to entering design (and a few who skipped the student route and came in from various paths).

The point is: there ARE entry-level design jobs. Why do people keep saying there aren’t? I have a few ideas:

  • aspiring designers tend to rule out entry-level postings because they read them unforgivingly (such as reading preferred as required)
  • aspiring designers tend to rule out entry-level postings because they aren’t qualified (lack of side projects, modding work, personal games, etc.)
  • aspiring designers don’t know how to find these jobs
  • the game industry is kind of infamous for non-standard job titles, so “game designer” may be entry level at one place but equivalent to creative director somewhere else
  • there are about one open entry-level design job for every one hundred hungry aspiring designers (these are totally made up numbers! but you get the idea – competition is fierce!)
  • it is common for aspiring designers and recent graduates to spend a long time (more than a year) trying to land that entry-level job


What Kind of Design Job is Entry Level?

First I want to clear up what kinds of design jobs are entry level, and what type of design jobs are not. This seems to be where a lot of confusion comes from when asking for advice or looking for jobs. This is a general rule of thumb, not some kind of law.

Content vs. Systems

When some people talk about “game designers”, they are talking about designers who are focused on the rules, mechanics, and systems in a game. At smaller companies, this might essentially be the lead designer or creative director. On small mobile projects they may be the only designer on the game. This demands a lot of prior experience, practice, and expertise. These are not (normally) entry-level positions.

So if you hear someone say that “design is not an entry level job” they are usually referring to systems and lead roles.

When others talk about “game designers” they are referring to everyone in the design department. The other type of design opposite systems – if I were to split them up – would be the creation and implementation of content. Some common examples are levels, quests, missions, and puzzles. Content designers may not be involved in the overarching rules and mechanics, but rather use those mechanics as a palette to create the game. Not all games have lots of content that can be designed, especially procedurally generated environments or gameplay focused on systems (think roguelikes or match-three games). But most AAA games have a HUGE amount of content and an appropriately sized design team to handle that responsibility.

So if you hear someone say that “design is an entry level job” they are usually referring to content designers.

Now, that is not to say that systems are better than content. At many companies, content designers also own systems, and content is obviously EXTREMELY important. It just so happens that it’s easier to split off content and implementation-focused roles into entry level positions than it is for systems.

If you are a aspiring designer who does not have prior (paid) industry experience in design, I suggest preparing yourself for a content designer position. This is why I recommend students focus their free time or coursework on creating games and levels in various AAA toolsets: it’s all about implementation.



So I want to debunk the, “There are no entry-level design jobs!” refrain right now.

To do so, I went around and collected a bunch of entry-level design positions currently available. Since these jobs may be taken down by the time anyone reads this, I’ve taken screenshots of them.

Please note: I am not advocating or endorsing any of these jobs. This is about giving you an idea of what an entry level job position reads like (so you can recognize them when you see them), and what kinds of work or qualification they expect from you. This is for illustrative purposes. It’s by no means an exhaustive collection – I only spent about an hour grabbing them.

Trends in Entry Level Positions

So I like data, and I realized after I collected the above job postings that I now have a whole lot of information about what different companies expect from junior designers! Luckily, there’s a lot of crossover in the content between all these jobs.

There are a few key elements that stick out as the most common responsibilities or requirements:

  • Great communication skills
  • Collaboration and teamwork
  • Work with all stakeholders in your work, across all departments
  • Write and maintain documentation

These are all mostly soft skills, and the only ones I think you can show off in a portfolio are documentation (this includes 2D level designs) and evidence of working with a team to create a game. I do want to reiterate: these are by far the most common requests on job postings, so if anyone thinks that game development is an antisocial activity then they are dead wrong.

After that, you start getting into the most important hard skills:

  • Experience in a game-editing program
  • Author and implement content (levels, quests, combat, puzzles, etc.)
  • Familiarity or working knowledge in scripting

Those are the most common ones. I don’t feel so bad now for my portfolio advice being so heavily biased in favor of implementing levels and gameplay in a 3D engine.

There’s lots and lots of other skills listed, with lots of one-offs (military experience? working with outsourcers?) that are specific to a single job and based on context. There’s just a few common or interesting details I found that I want to call out:

  • Degrees are usually preferred, not required, if they are listed at all. They often aren’t listed on the job posting at all.
  • Programming experience is very desirable, and a good portion of entry-level design jobs involve scripting.
  • Several entry-level jobs involve acting as support for more senior designers, who will rely on you to implement and iterate on their designs.
  • Many list a specific genre, game series, or gameplay mechanic that they wish applicants to be familiar with. This makes sense where, if you make FPS games, you would want a new member of the team already up to speed on FPS mechanics.
  •  At least one asks for evidence of major gamer cred (high level MMO character!) but I have seen similar requests in other places. This is unusual, but not unheard of.
  • Design skills are usually vaguely defined (“understanding of fun”) or as a long list (pacing, flow, systems, mechanics, etc.). The point here is that if you are applying to a design position, it’s just understood that you should be knowledgeable about all the elements of game design.
  • There really is a pretty big range of jobs, once you get passed general design skills, from mobile jobs with more business-related skills, to level or combat encounter design big AAA studios, to scripting-focused jobs that lean on programming knowledge.

The last thing I want to cover is “prior experience” since this is a sticking point for a lot of aspiring designers that I talk to. I get the feeling a lot of people opt out of applying to jobs if they ask for prior game development experience, without realizing that this totally includes side projects and other portfolio work. Prior game development experience, if it doesn’t reference a shipped game, means that experience you earn on your own (school, modding, side projects) still counts. This is something a lot of people get caught up on.

If a job posting asks for 1-2 years of experience in the industry, I personally tend to read these as entry-level. I encourage students to apply to them anyway, assuming you fit the other criteria, and instead read “in the industry” as “modding or large game projects”. Once you get a bit further, into 3-5 years, the jobs tend to be looking for people who are more traditionally experienced at companies.

If a job specifically asks for a shipped game, they generally mean traditionally shipped (such as a console or mobile title) and as part of a paid position at a company (not a side project, or game you made by yourself).  Remember how common communication and teamwork skills were? There’s a huge difference between working alone on a game and working as part of a team.

As always, there are all kinds of exceptions to what I’ve written above but, mostly, I’m hoping that some people feel a bit more comfortably finding and applying to entry level jobs, and if they don’t at least realize what skills they need to work on to break in. Please note that my examples I included and pulled from aren’t a real sample size – just what I could find in a short time period. There are lots of other entry-level jobs out there, and many of them have their own needs and idiosyncrasies.

From Student to Designer: Part 5 – Interviews

As usual, my advice is specific to design and to seeking a more traditional job in AAA development, as opposed to breaking in as an indie, but most of it can be applied elsewhere. This is just my personal advice, so I recommend getting others to review your work for second and third opinions, and ultimately make your own decisions.

Part 1: Websites & Resumes
Part 2: Portfolios
Part 3: Cover Letters
Part 4: Design Tests
> Part 5: Interviews
Part 6: Entry Level Design Jobs

I will be honest: I have never had to interview someone for a job. I’ve never been on that side of the table, so some of my advice might be a bit vague, so I’ve leaned on friends to help me with writing this. This article touches quite a bit on “general employment topics” which is mostly outside of my purview. (If you are already in the industry or had professional interviews before, this article won’t really tell you much you don’t already know).



Interviews and design tests and all that jazz are really nerve-wracking for a lot of people, like a first date with someone you’ve admired at a distance for so long and now finally you have their attention and all you can think about is if there’s food in your teeth. My goal with this article is to demystify the interview and hiring process mainly for students who have never gone through it before. Along the way, I’ll give you some tips on what to do.

Typically, the process of getting a job as a designer at a game studio goes like this:

  • Resume, Cover Letter, & Portfolio submitted
  • Interview over email
  • Informal Interview
  • Phone Interview
  • Design Test
  • On Site Interview
  • Offer Letter

Many studios skip steps or change the order of them. This isn’t some kind of formula that companies follow, but rather common sense.

(You can always count on the offer letter being the last step though.)


Resume, Cover Letter, & Portfolio submitted

See my previous advice for resumes and cover letters, and for design portfolios for more details! Below I’ll go over all the different ways I know of where a resume ends up in a studio’s hands.

  • Fill out an application, usually through a website form. These can feel impersonal (they are) and as though your resume will just end up in the trash (they won’t). These are common at big studios and publishers that get thousands of resumes for a single job opening.
  • Use an email provided by the studio (such as jobs@companyname.com) to send your resume, using the email content as a cover letter, and any other information they’ve requested. More common at smaller studios.
  • Get recommended personally by someone already working at the studio for an open position.This is why networking is so important, but remember that most people will only recommend those they’ve worked with in the past, which doesn’t really help entry-level people.
  • Visit a career booth at a convention (like GDC, PAX, ComiCon) or at a career fair set up by your school. Often they’ll still have you submit your resume via email or through an application, but sometimes they accept them.
  • Get laid off from a high-profile studio… is not a technique a recommend. When a studio has a large number of layoffs or closes down, such as Irrational Games after Bioshock: Infinite wrapped up, other studios go in to snap them up (starting with leads and working their way down). Sometimes there’s actually a career fair organized in the former offices.
  • Get recruited directly by studios who find your information on LinkedIn, any social media presence or blogging you do, or even word-of-mouth. Unlikely for students (though this is actually how I got my first job back at 5TH Cell). Pretty common among people with lots of experience.
  • Get recruited by external recruiting agencies who look for individuals that qualify for job postings, and then connect the applicant with the employer. They take a slice of your income, or the studio pays extra on top to the agency. I would not use recruiting agencies if you’re a student. Probably never use them, but that’s a separate topic.


Interview Over Email

I don’t think email interviews are particularly common – phone interviews mostly cover this. But I have run into it before with a studio, where they asked me some general questions to see if I was a good match. I didn’t do any email interviews with any others, so no idea how prevalent this is. However, remember that any email correspondence you have with someone at the company, even if it’s with a receptionist, is basically an interview. Always be polite and professional.


Informal Interview

These aren’t exactly real interviews. I call them “sanity checks” because their goal is to mostly check that you seem smart, know your stuff, and are the kind of person the interviewer might want to work with in the future. It acts as a convenient pre-screen for a real interview.

You can find informal interviews at networking events or conferences like GDC where a bunch of people from different parts of the world are suddenly in one place so it makes total sense to just talk to those you might want to hire. I don’t think anyone is exempt from this possibility, but usually they are arranged ahead of time and not really spontaneous. I’ve done probably a dozen informal interviews as the interviewee – some pretty bad (as in, obviously not a good fit for either of us) and some with more traditional follow-up interviews.

I’ve conducted a couple informal interviews, which is the limit of my experience as an interviewer. Normally I ask general design questions, games they admire, whether they are into systems or level design or what, and just get them talking about design and an idea for what they are looking for job-wise The stakes aren’t particularly high and you aren’t going to get a job offer directly from one of these, but they can feed into future opportunities.


Phone Interview

The first phone interview I ever had was for an internship and I had a chest cold so bad I was afraid to fall asleep because I’d stop breathing. It can’t get any worse than that and I still got the internship. So just remember, as long as you can breathe then you can do it.

Phone interviews are the real deal. You’ll talk to either one person, usually a lead or director, or several in a conference call. They’ll ask you questions about design, about your career goals, and about why you want to work there. They may ask you some questions that require you to design on the fly. Sometimes you’ll have a pre-screen phone interview with a recruiter or HR personnel  employed by the company. That is different – not a real interview (so to say), but rather another gut check.

Phone interviews and on-site interviews are very similar, with similar types of questions, so scroll down to my “interview tips” section for an idea of what you might talk about.


On-Site Interview

By the time you get an on-site interview, the studio is probably pretty sure they want to hire you and this is just the last test. Exceptions are when you already live near the studio and they decide to take a chance and ask you to come in. But if they are flying you in from out of town and putting you up in a hotel they are probably serious – no one will spend that money on someone they aren’t sure about.

This also means the stakes are really high for on-site interviews.

Typically (and remember, there’s always deviations!), these are full-day affairs that involve interviews with lots of people, not just your direct head. Almost everyone I talked to shared the same experience at big studios: you’ll start in the morning, have lunch with some subset of the team, and then continue through the afternoon. Sometimes the morning or the afternoon is taken up by an on-site design test, and the team takes you out to dinner. I know a couple people who had multi-day interviews when they were flown out pretty far (think: US -> Europe). You may have one-on-one interviews, or with a few people at a time, and they’ll rotate in new people – designers, leads, directors, and developers in other departments that you would be working closely with. Smaller studios might have people spend longer with you since they have smaller teams and more of a chance to get to know you personally.

If you end up in an assembly-line style of interviews, you may get a lot of repeat questions since interviewers aren’t going to compare notes until after the whole process is over. Remember that none of these people are “professional interviewers” so some of them will have awesome or difficult questions, and some might be a bit more lukewarm or adversarial. You just never know.

There is usually only one on-site interview, but some studios may call you back for another interview with new people. (I’m looking at you, Riot Games and your 6+ on-site interviews I keep hearing about.)


Design Test

Not all studios have design tests. Not all design tests are the same (they vary wildly between studios). There’s not much to talk about here since I’ve covered the bulk of design tests in a previous article. Design tests may appear at any time – on-site, remotely, before or after interviews (though, obviously, they won’t show up after the offer letter).

I personally would not do a design test unless a studio has already interviewed me, in person or over the phone. Most studios seem to follow this out of respect for your time and their own  since it takes effort to conduct and evaluate a design test.


Offer Letter

Some time after having an on-site interview, you should get a response: yes or no. Sometimes the response might take a few weeks if they still have interviews they want to conduct for position to narrow down their list because, remember, you are competing with others for the same job opening. It may also take longer if they offer the position to someone else and they turn it down, leaving you second or third in line. (If they are nice, they won’t tell you that you weren’t their first pick.) If you don’t hear anything back, well, that’s kind of unprofessional but could also be an oversight, so my rule of thumb is to wait a week before emailing a followup.

Offer letters come with a job title and brief description of your duties, a starting date, and a salary offer. You’re expected to sign it and send it back if you accept the offer. This is the point where you can negotiate salary, ask for details on their benefits, what kind of support they give for relocation, visa/international worker issues (which I don’t know much of personally), and if you need to change the starting date. They are usually really flexible about all this stuff, though salary negotiations are always hit or miss. If you have more than one offer from a company, you can use that to help negotiate.

Offer letters typically come with an expiration date! They don’t want you hoarding an offer letter while applying to another studio solely as a bargaining chip, and they don’t want to wait too long only to find out you don’t want the job. If you find that you need more time, you can always ask.


Basic Interview Tips

So now that you know the process, I’m going to go over basic interview tips specific to games.

  • Dress casually. Jeans are FINE. Sneakers are FINE. Game-related tshirts are FINE. If you want to dress up a bit, then swap out jeans for slacks or a skirt, sneakers for nicer shoes, and making a button-up shirt. Do not wear ties or full suits to your interview. Wear something comfortable first, good-looking second.
  • At a traditional game studio, don’t worry about neon hair, piercings, or tattoos. It may be worth toning it down if you’re interviewing at a studio that’s not part of the tradition games industry or tech (such as educational games and government-funding training sims), but this is really your call.
  • If you have no real interview experience, mock interviews with a friend might help you, where they pretend to be an employer and ask you questions. Personally, I did really poorly in mock interviews compared to the real ones but I think it got my nervousness out of the way.
  • Bring a couple copies of your resume. I’ve never had to use them, but they make me feel more prepared. Don’t worry about printing or bringing physical copies of any portfolio pieces, but if you want to be extra prepared you could put some of your work on a USB drive.
  • Know about the studio’s games and its history. Some studios require you to be a regular player of their games (Blizzard and Riot come to mind), while other studios just ask for a passing familiarity. It’s good practice to be able to talk about the studios games if you’ve asked about them.
  • If you know what game the position is for, make sure to read as much as you can about that game. If there are prequels or other games in the series, try to get your hands on them (even if it’s just a demo). Arm yourself with knowledge about other big games in that genre.
  • If you were a student, if someone asks about your experiences make sure to talk about what you did personally, not what your student team or class accomplished. Try to isolate your contributions because they should want to hire you, not your classmates.
  • Don’t pretend to know an answer. Don’t lie about a game you haven’t played or  fake your way through part of an interview. These are terribly transparent, especially since a lot of questions (see below) actually lead to more in-depth discussion. Instead, be honest if you don’t know the answer or if you haven’t played a specific game.
  • Be a little humble, even though you are there to try to impress people. One of the goals of the interview process is how you would work well within the team. Some team structures are kind of antagonist, but most of them are very cooperative and developers want people that are easy to work with.


Questions THEY Ask

I categorize questions people may ask you at an interview as: general interview questions (not specific to games), general games talk, and design on the fly.

One secret? Sign up at Glassdoor.com, look up your favorite companies, and read the comments people leave. Some wonderful unscrupulous souls love to leak interview details there. Here’s 32 pages of interview questions for “game designer” positions.

General Interview Questions

You’re going to run across some number of these and I don’t think they are all that interesting for the most part (I prefer design-specific questions). For an extra resource, check out this list of the 50 Most Common Interview Questions (with some advice on how to approach them).

Some examples:

  • Why do you want to work here?
  • What was your experience at [previous studio] and why do you want to leave?
  • What is your greatest weakness? (Correct answer: attention to detail)
  • What is your greatest accomplishment?
  • If you don’t already live in the city, what do you think of it? (And similar easy, chatty questions, including “the weather”).
  • Where do you see yourself in five years?
  • Can you give me an example of a problem you had with a team member, and how you solved it?

General Games Talk

These are mostly questions that will delve into the types of games you play, what you think about them, and whether you can communicate interesting insights into other games. A lot of times they are questions that lead into design-on-the-fly questions.

Here’s a smattering of questions I would prepare to answer:

  • What games have you been playing lately?
  • What’s the last game you played? What did you like about it?
  • What’s your favorite game of all time? Why? What would you change about it?
  • What’s your favorite genre? What games do you feel epitomize the best practices in that genre?
  • What’s your most hated genre? (Don’t say the genre the company specializes in…)
  • What are some cool trends in games that are interesting? Or, here’s [trend], what do you think about it? (examples: free-to-play, esports, virtual reality games, next-gen consoles, etc.)
  • You worked on [game]. What was that like? What was your process? What would you have changed?
  • Tell me about a time when you had to [fill in the blank].
  • Can you give me an example of a design problem you had, and how you solved it?

Now, when they ask you about games, don’t be afraid to be honest. There is no wrong answer here and no one is going to judge your tastes in game so long as you can back up why you liked it and whether you know enough of the medium to compare it with other, similar games.

If someone asked me what games I’m playing lately in an interview, I’d probably start off mentioning that I am playing through some cool indie interactive fiction at the moment. But if I am interviewing at a AAA studio, I’d also follow it up with the fact that I’m playing FarCry 3 for the first time. Since I know that they are fishing for a game in common, mentioning obscure games doesn’t really help beyond giving them an idea of my range of tastes or perhaps introducing them to a new game they haven’t heard of (obviously, with an intent to see if you can explain a game’s mechanics to others).

Really, all these questions are created to get you talking about games and talking about design with fellow designers. They want to know if you can speak their language and have insights to share with them.

Design on the Fly

These questions are pretty devious, but also really powerful tools. They want to know your thought process as you go through it on the spot. They want to know how you solve problems, and if you can solve hard problems (or, at least, tackle them) or if you freeze up.

The important thing is to talk through the problem they give you and not just go silent and try to deliver them a perfect response.

Here’s a few examples of “design-on-the-fly”.

  • If you had a billion dollars, what game would you make? These types questions are open ended on purpose, asking you to just brainstorm away. (I don’t like these questions and I think interviewers should stop using them.)
  • How would you redesign a given game for a different control scheme? For example, talk me through adapting a third-person shooter for a touch screen. (Kind of similar to some of the design test questions, but more manageable)
  • So you said you’ve been playing [game]. How about you talk me through a new mission you’d design for it?

A friend – I cannot remember who! – told me my favorite story for tricky interview questions. The interviewer asked them about an example of a problem they had with a team member and how they solved it. So they described an artist who made a clock tower centerpiece that just did not conform to the needs of design. So, the interviewer stood up, walked to the white board, and proceeded to draw a pine tree. “This is my clock tower.” And then they waited for the interviewee to explain the problem.

As you can tell, these questions are pretty context specific – it really depends on what your common frame of reference is, or what the interviewer is interested in at the time, or what topic is just floating around the room.  I don’t believe you can ‘cheat’ these questions by practicing answers, or even prepare all that much for them in advance.


Questions YOU Ask

A lot of people tend to forget that the interview process is a two-way street. You have as much right to interview them as they do you. Ask them questions that show you are interested in the company, how it functions, and making sure it’s a good fit for you.

I think most people have a few key questions they learn to ask. My personal choice has always been to ask, “What is your crunch policy?” This puts some people off-guard, since no one likes crunch or likes admitting how much they crunch but, seriously, everyone crunches. Others may let slip that the studio has awful amounts of crunch (useful information, whether or not you’re willing to crunch like that). But good studios don’t have a problem answering this question and showing that they’ve thought about it. This is my pick, but you may not agree (some designers I mentioned this to said they would never ask that).

Some ideas for questions you can ask (if you want!):

  • What game is this position for? This is in case it’s a studio that hires for multiple projects, and didn’t specify. Sometimes the game is under NDA and they aren’t willing to discuss it, unfortunately, but at least that’s information that you’d be working on a new unannounced project.
  • What is the size of the team? How is the department structured (one lead, multiple leads, etc.) Probably a better question for smaller studios that have nontraditional hierarchies than larger studios.
  • Do designers fill specialist roles or are they generalists? Are they responsible for very specific content or do they take on multiple responsibilities? If you are applying for a level design job, for example, you may want to ask them what the workflow is like, whether you are involved in mission or combat setups or just world building.
  • What kind of scripting, if any, are designers responsible for? Do designers do any work in 3D modeling tools (like Maya or 3D Studio Max) or do they whitebox content directly in the engine tools?

A piece of advice I’ve heard is to get the interviewer talking as much as possible, rather than the other way around, and they’ll leave thinking you’re awesome. Don’t be afraid to let the interview derail – I’ve talking to people about travelling, hiking, delicious Thai food, and how awful Frank Herbert’s Dune series gets after the second book. This is fine, and a welcome diversion for people who don’t really like interviews (who does?). The next person or the next break will get the interview back on track anyway.

Q&A: Junior Positions, Experience Required

Most junior programming positions I’ve seen so far require 2 years experience, did you apply for jobs that expected more knowledge then you had at the time? If so, were you honest saying that you didn’t meet all the criteria?

First off, have you heard the joke about the job that asks for “5+ years of experience with the PS4” (or another, equally impossible, endeavor)? If you haven’t heard about this… well, it’s not just a joke – it’s something that actually pops up in job listings. Business people without knowledge of technical details and startups are particularly bad about listing qualifications that describe senior level responsibilities, but for a junior position. Beware of these. They are likely looking to underpay you, or have unrealistic expectations of the amount of work you can do.

Now that’s out of the way, let’s get to the details of this specific Q&A.

Two years of experience is not to much to ask for a junior position. The question then comes down to, “What counts as experience?”

Personally, I would consider upper-level coursework, internships, and time spent on personal (but substantial!) projects as experience. You need to be honest with yourself, though. If your programming reflects a couple courses taken over two years… that’s not two years of experience. If you graduated with a CS degree and did some independent projects that are directly related to game development (or to the position in question), then maybe that’s enough to qualify.

It does require some introspection. Take a look at all the other qualifications listed and ask yourself if you are actually able to do that kind of work. Don’t apply to a senior position if you are obviously not a senior level candidate. If a company asks that you’ve shipped a game on a specific console, you should probably only apply if you’ve done that since it means they are looking for specific experience. If a company asks for someone with a few years of C++ and all you took was a couple courses in college, you probably aren’t what they are looking for.

But “two years of experience” is one of the fuzzier job requirements. If it said “five years of experience” then they are looking for people who have worked in the industry previously as professionals. Two years is short enough that all it means is that they don’t want someone brand new and doesn’t know what they are doing. They are trying to weed out fresh-faced college grads that will apply to jobs in droves because the vast majority of them are terribly underqualified. If you otherwise fit the criteria for the job, then go ahead and apply.

Whatever you do, don’t admit you don’t meet the criteria. That’s like saying “I read the rules but decided they didn’t apply to me.” Just apply. Just remember to only apply to jobs that you believe you’re reasonably qualified for. If you aren’t, your resume may not just end up in the trash but also on a blocklist with a long cooldown timer.

(And yes, I applied to positions that I was not qualified for based on years of experience. I don’t remember if I ever heard back from any of them. Take that as you will!)

As usual, if you have questions about game development, feel free to email me. Sometimes I’ll ask permission to post a question to my blog anonymously if I think it’s something others may want to know.

From Student to Designer: Part 4 – Design Tests

As usual, my advice is specific to design and to seeking a more traditional job in AAA development, as opposed to breaking in as an indie, but most of it can be applied elsewhere. This is just my personal advice, so I recommend getting others to review your work for second and third opinions, and ultimately make your own decisions.

Part 1: Websites & Resumes
Part 2: Portfolios
Part 3: Cover Letters
> Part 4: Design Tests
Part 5: Interviews
Part 6: Entry Level Design Jobs


What Is a Design Test?

A design test is a test of your design skills where a studio asks you to perform some kind of design work as part of the interview process. Usually a design test is timed (i.e. one week in your spare time seems to be pretty common). Sometimes the design test is on-site as part of the interview process, where you are given anywhere from one to four hours to complete an assignment by yourself.

I’ve done several design tests, been given (and passed on) a few more, and even designed one. When writing this article, I reached out to a lot of other people in the industry for their advice and experiences. The type of work varies depending on what kinds of games a company makes and what work designers do there. Design tests may ask you to:

  • Analyze or deconstruct mechanics or systems in an existing game
  • Take an existing mechanic or system and propose changes to meet a new design goal
  • Design and document a chunk of new gameplay in an existing game, such as a new feature, gameplay mechanic, weapon, boss, puzzle, etc.
  • Design and document a new level or mission to an existing game or within certain parameters, including all the information needed to put that level into production.
  • Implement a level in a particular toolset.

These tests are pretty always specific to the studio. A company that makes puzzle games will have a design test that involves designing a puzzle, whereas a company that makes third-person shooters will probably have you design a level for one of those. A mobile company that makes free-to-play games may test your knowledge of monetization, the audience, and platform, but a AAA studio probably won’t since that’s not part of the job of a designer. So the best way to prepare for a design test is to know what kinds of games the studio makes.

The design tests usually have a number of requirements and limitations that they expect you to follow when doing the test. In my experience, these kinds of constraints are usually realistic and mirror normal development of a game, thus keeping the scope of your work in check.

Not all studios have design tests. Studios that do have design tests may only selectively choose who needs to complete them or give them to everyone no matter the position. I think they are more common in junior roles, where there are more applicants and those applicants have less experience, so as a student (which you, reading this, probably are!) you are likely to come across them.


Why Are There Design Tests?

The design test is a supplement to the interview process – it’s just another way to filter applicants and find out which one is best for the job. Most design tests are sent out before or between interviews or take place during an on-site visit.

There’s a few key things that someone can discover from a design test that can be hard to learn otherwise:

  • Evaluate your skills in the genre assigned, assuming you have no previous professional experience.
  • Help identify designers that will need to be micromanaged and hand-held through the design process, as opposed to those that can make intuitive leaps and show initiative and creativity.
  • If you have a realistic understanding of game development process and scope of work you’re detailing out.
  • If you care about the quality of your work and will finish your work to a high standard of polish. I can see this in the presentation, completeness, and quality of the design test submission.
  • If you’re able to communicate your designs clearly and effectively in ways that everyone, not just designers, can understand.
  • If you can plan ahead for many different test cases (“what if the player does x?”), and spec out mechanics with a certain level of completeness. This is kind of asking if your design is water-tight.
  • If you can plan ahead for all kinds of details that affect other departments. Examples: audio cues, lighting, dialogue and story moments, cinematic events, identifying destructible objects or new assets specific to newly-design mechanics.
  • If you did proper research on, and have familiarity with, the studio’s games, or games in the same genre.
  • If you can follow directions!

One thing to keep in mind is that while a design test is a “test” and not final work, I would treat it like you are documenting something that needs to fit into a final game. Work on it knowing (‘pretending’) that this is work that you need to make as part of your job, and that you may be handing it to your leads or peers for review or to other departments as information they need to know.



So when asking others for their experience with design tests, a lot of people shared real-life examples, many of them old and no longer being used, and others actually available publically (if you know how to google for it).  I’ve still summarized and anonymized them since it’s bad practice to share design tests verbatim (it’s kind of like sharing exam questions during finals week). This also means I changed a bunch of key details so, no, don’t expect to see these exact ones anywhere. The below examples come from a big cross-section of studios, from indie to mobile to AAA to third- or first-party studios.

It’s common to see a combination of design tasks that ask you to analyze a game, modify a game, and design a new game (substitute “game” for “mechanic” or “level”). A smaller subset also asks you to implement that game (or mechanic or level) in a game development toolset. This is how I’ve divvied up the types of questions or tasks assigned. But design tests can be anywhere from one to ten different tasks, depending on the studio and the questions they are asking.

Analysis Examples

  • Take two games and analyze their strengths and weaknesses.
  • Take the studio’s existing game and create a flowchart of one of the gameplay loops.
  • Take a successful free-to-play game and analyze it. Explain how monetization works.
  • Deconstruct a competitor’s game and analyze its structure and gameplay.
  • Take an existing game and pick one feature that you think it does best.
  • Deconstruct a level you have shipped in a previous game, including your design process from beginning to end.
  • Compare and contrast how two games implemented the same feature
  • Document a given gameplay mechanic

Modification Examples

  • Take the studio’s existing game and identify a feature you would cut, and explain why.
  • Design a new feature for the studio’s game
  • Balance gameplay values for a specific design goal, such as with a spreadsheet
  • Take a singleplayer gameplay mechanic and adapt it for a multiplayer environment, or vice versa
  • Take an existing premium game and explain ow you would make it free-to-play with monetization

Creation Examples

  • Design a game that could ported to a different platform at a later date, such as the iPhone or Oculus Rift.
  • Design an extensive first-person shooter level in an existing franchise
  • Design a new mobile game, and spec out all the relevant details (story, setting, abilities, puzzle elements).
  • Design a choice-based dialogue tree that fits within an existing franchise. Spec out the consequences/rewards for each path.
  • Design a pitch for a new level in an existing franchise, including level design documentation.
  • Design a level that suits both singleplayer and cooperative gameplay mechanics for a given franchise.
  • Design a new weapon, ability, enemy, or mechanic that fits into an existing game.

Implementation Examples

  • Design and implement a new mission or level with our in-house (3D) tools, including new gameplay mechanics.
  • Design and implement a new level with our in-house (2d) tools, including new gameplay mechanics.
  • Design and build, in the engine of your choice, a singleplayer combat space.
  • Design a new level for an existing singleplayer game, and then implement it in the engine of your choice.
  • Take a level design document and use it to implement the level with our in-house (3D) tools

Now, keep in mind: there’s a bunch of design tests easily within reach if you use google. Tests are normally a lot more specific – I’ve seen everything from one sentence to several pages of specifications. Like I mentioned above, tests are usually context sensitive to the studio you are applying for. If I applied to, for example, the studio that makes Assassin’s Creed, I might expect a test on creating a mission for an open world game, or designing a space meant to be traversed from many angles, or to design a new stealth weapon for the player to use.



Below I’m going to outline some tips on how to complete a design test which, depending on the size and questions asked, can be pretty daunting.

Some of these seem like a lot, and they are. Doing paper level design layouts gets a LOT easier with practice, especially if you have some development experience behind you. So if you go around and compare your results to professional level design documentation, don’t get too disheartened.

When I talked to fellow designers in the industry, the main pieces of advice that came up were:

  • Follow the rules!
  • Understand and use space, scale, and metrics appropriately
  • Flesh out story, character, and drama as it pertains to player experiences
  • Presentation of the final submission matters
  • Be thorough and concise in any written portions

Follow the Rules

This advice is first for a reason! Some tests are deliberately vague, which means that part of the test is you coming up with the right set of information to communicate your design. But this is uncommon among design tests – typically, there’s a whole ton of very specific details they want you to follow.

“Design a level with one unique platforming element, two visually distinct areas, and three enemy types. The enemies must fulfill requirements X, Y, and Z. The platforming elements must do A, B, and C. The player can move at speed G, jump at height H, and has abilities M and N. Introduce ability O halfway through the level.”

That’s a made up summary, but you get the idea – tests can get very specific. Sometimes a person hands in a test and the applicant made the most awesome level… but instead of one unique mechanic, they added three, and instead of an outdoor level, it’s a cavern.  If they can’t work within the guidelines for a test, how are they going to work within scope on a 50-person team? Or, if it’s an indie or mobile studio, they may be thinking about budget right there. In practice, a designer can be told “you can have ONE new thing in your level, but you got to make it worth the work.” That’s part of what design tests are going for – they want to see you take on these restrictions and still surprise them.

Mind you, no one likes a rules lawyer. I suggest you follow the intent of the rules, and don’t try slipping anything in under a technicality. If you realize you’ve been fudging the rules, then either scale back or admit it and address it in your documentation – give alternatives that cut down the scope if your initial proposal can’t work.

Space, Scale, and Metrics

This advice is specific to level design tests.

Designing levels can be hard unless you have, and follow, a set of metrics. Know how fast a player can move, how high they can jump, what the optimal range for combat is, how wide a hallway is, how many steps make up a realistic staircase.

Most game companies put all their metrics in meters so if you’re an American you should get used to this.It’s also a lot easier to design spaces for humanoid characters in meters – a person 2m high (6ft), a nice even number. 2D sidescrolling games are a bit different – you may measure things in tiles instead. Below is an example of the kind of metrics you’d want to take into account when designing a 3D space:

The player is 2m high and about .5m wide and can move at 8m/s. Low cover is .5m high, and high cover is 1m high or larger. Roofs are at least 4m tall. Hallways are 6m wide at minimum. Stairs and ramps can rise at a rate of 1m over 4m horizontally. Optimal combat distance for assault riffle like enemies is around 30m, and snipers around 60m. Combat focus should change no more than 90 degrees from the player’s current heading.

Now, don’t follow those metrics exactly – it changes for every game, and every genre, and there are major considerations for singleplayer vs. multiplayer (the latter, of course, needing a lot more space). The sooner you get into the habit of following metrics, the better.

When creating maps, make sure you’re accounting for these metrics and scale. Create a set of objects or symbols in your layout tool of choice (photoshop, etc.) that represent reuseable chunks of your level – floors, walls, pieces of cover (if applicable), doors, interactive objects, etc.

Some things to think about when you’re designing a space on paper, especially a 3D space mapped to a 2D layout:

  • Check the height of ceilings and make sure the player won’t bump their head, have difficulty moving around in, has room for a camera to float around in if this is a third-person game, or that it doesn’t seem too massive or tiny.
  • Think about what the player can see at any given point. Look at the level through their eyes. Take into account what may be occluded or revealed as the player moves through the space.
  • Use a variety of scales to create different moods – claustrophobic spaces and giant open spaces feel very different. When navigating through an environment, switch these up.
  • Clearly identify the boundaries of the gameplay space, especially in outdoor environment. If the player decides to wander away, what stops them from leaving the area?
  • Use a variety of different shapes. Most pieces of geometry are built off of rectangles, but don’t be afraid to add curves, circular rooms, or structures with many sides (hexagons, octagons).
  • Take into account verticality, especially in 3D level design layouts. Balconies, bridges, staircases, pits, hills, elevators, ziplines – all of these can add interesting elements for the player, whether it’s combat, traversal, exploration, or puzzle-solving. All good 3D games make use of these elements, so learn to design with them and how to illustrate them on a 2D layout.

Story, Drama, and Character

In any test where you are designing something with a narrative, you should take into account the overall story and feeling of the level or mission. On the job, you may not be writing the story itself, but you might be responsible for deciding what the player’s moment-to-moment goals are, the pacing of the level as tension rises and falls, and what makes the level (or mission) thematically tied together and stand out in the player’s mind.

One tool I recommend is to create a small pacing chart. This is a graph of the intensity of the level over time, so you’ll see a line that rises and falls and spikes at certain moments. On this line, you mark out major events – new mechanics, combat encounters, boss battles, cinematic or story moments, new visually distinct areas, etc.

If you have 20 minutes of gameplay, then at about 15 minutes you should hit the ‘boss battle’ or the major end climax. At about minute 5 the introduction should be over and real challenge arise, About halfway you might want to surprise the player (i.e. the objective reveals a new goal, they’ve reached a new area, etc.). You want to have highs and lows of intensity and mix where story development goes (low intensity moments) and where the action takes place (often high intensity moments). Obviously, what a “high” and a “low” are depends on the genre – is it a puzzle game or a first-person shooter? (Don’t ask me about pacing in roguelikes – if that’s what’s on your design test, good luck!).

When you’re doing a level design test, I highly recommend you make one of these – even if it’s a thumbnail size – and use it to keep a birds-eye-view on your content.

Here’s the kind of questions you can ask yourself while you’re designing:

  • What are the highs – the most intense points – and lows? Is there too much non-stop action, leading to player fatigue? Is it too slow without enough action or reveals? What surprises the player?
  • What is the mood of a specific space or area? Haunted and suspenseful, or Hollywood Action Film? This kind of information informs art, lighting, audio, fx in that area (explosions going on in the background? Low-level fog everywhere?).
  • What are the major cinematic moments?
  • Do you have allies with you or NPCs that can contact the player? Are there intel drops, notes, or other written information in the level? If so, what kind of information do they give the player?
  • Did you design a boss or enemy? What kind of motivations do they have? Does the environment they are in and their abilities match the enemy design? Does the space need different considerations based on the enemy, such as a flying or swimming enemy, or one many times the size of the player?
  • Is the ending satisfying, narratively? Did the player succeed, or did the villain get away? Does it both satisfy the player (give them something they feel they accomplished) and leave them with a cliffhanger (inviting them to continue playing)?

Presentation Matters

Hand in a highly polished presentation. As a fellow designer said, “Pretend you’d submit it as a walkthrough published in a magazine.” That seems like a high bar but… you are competing against a lot of people who want the same job. Do the best work you can do, but present it nicely too. One of the reasons presentation is important is that it’s a reflection of the quality of work you do and your commitment to polish.

Some tips for improving presentation (mostly applying to level design layouts):

  • Unless you are a professional illustrator, don’t hand-draw level designs. Use software like Illustrator or Visio or Photoshop and it will be much easier on you, and you can fix mistakes faster.
  • Use color and icons, and include a key. I want to be able to scan your map and find all enemies, all objectives, or all pickups at a glance (for example, enemies are red circles, objectives are yellow, pickups are blue).
  • Include annotations and callouts for key events or moments for the player throughout the level, and number them so I know the order in which the player encounters them. You can do annotations with just numbers as a second sheet that says what they are, but I think putting them into the map itself as description bubbles (and keeping the text short!) is more effective.
  • Use side diagrams as needed, even if they are thumbnail size, to help communicate the 3D environment when you’re drawing it on a 2D page. Don’t worry about isometric layouts – they are notoriously hard and I don’t think anyone expects them.
  • Check for spelling and grammar. If you don’t have someone else to proofread, then read your work aloud to yourself.
  • Ask someone to look over your work and give you feedback, particularly another designer or someone with good design sense.
  • Look at video game walkthroughs for examples of concise, clear instructions and ideas on how to layout, color-code, and communicate content in your map.

One thing I would suggest: if you’re making a 2D layout, and the design test doesn’t ask for it to be printable, don’t worry about fitting it into several 8.5″ x 11″ sheets of paper. My experience is that people in the industry all look at layouts on the computer anyway, usually as a .PDF, so it can be any size or shape needed to fit all the content into it, with the viewer zooming and panning for additional details.

Complete, Thorough, & Concise

The ability to write clearly and concisely is a skill honed from years of practice. (When it comes to concise, based on the length of my articles, I am certainly not there yet). One thing I’ve seen on friends’ design tests is a lot of words to say relatively simple concepts – long paragraphs, not much use of white space, too many long sentences that lose sight of the original goal. It can be hard, but really try to pare down what you’re saying into short manageable chunks.

If you have to detail out a level or a new game, make good use of headings, bullet points, and lists to help separate content and make it more readable. Images can say a lot, so think about adding small sketches to illustrate your points – sometimes it’s easier to explain the pacing in a level with an image than with several paragraphs. Imagine that someone needed to take your document and know everything possible about a single element – how easy is it for them to get that info?

Remember, treat anything you write as though it needs to be used by others (leads and peers at your studio, in and out of the design department). One of the ‘truths’ of game development is that no one reads documentation – the reality is that most documentation is bloated and written poorly and hard to keep up to date. Write your document and then imagine putting it in a time capsule and pulling it out a year later to update it. How easy will it be to make the relevant changes? Will you need to read (and re-read) the whole thing? Can you scan it to find the details that you need to change? Are all the details there or are there things missing? This gets into what I referred to early as water-tight – taking into account “what if the player does X”.


When To Refuse a Design Test

Sometimes it’s worth your time to do a design test, and sometimes it isn’t.

I would advise against doing a design test if you haven’t already talked with someone qualified to hire you (i.e. a lead or director, not HR). I don’t think studios should ask applicants to invest the time in a design test if they aren’t already serious about hiring them. But there are many studios that send out tests blindly, so it’s your call as to whether to engage.

Remember, you are interviewing the studio as much as they are interviewing you. If a studio sent me a design test via an automated response immediately after applying, I would say they failed the interview. (This has happened. I decided I did not want to work for that studio).

Not all design tests are created equally. Of those I’ve seen, I think most of them are fair and several of them ask much too much of applicants. I probably wouldn’t do a design test that had me implement a level with scripting in an engine from scratch, no matter how cool the job. But I may be willing to do a lot more work for a highly desirable and competitive studio (like, say, Epic Games) than a new mobile startup with a short history.

There are conflicting opinions on the usefulness of design tests for judging applicants, and whether they are potentially exploitative by asking people to do unpaid work in exchange for the chance to get a job. The latter is known as “spec work” and you’re more likely to run across it in art and graphic design roles in entertainment and advertising. There are also exploitative companies out there that may ask an applicant to do a ‘test’, turn them down for the job, and then go on to use their work in the final game anyway (with questionable legality). Some people have valid worries that if a studio asks you to do a ridiculous amount of work for a design test, then they may be equally exploitative to their own employees (crunch hours, poor quality of life).

For some further reading, I recommend the blog post “Just Say No To Employment Tests” by Stephen Dinehart – you should definitely read the comments for the variety of responses and opinions.

Personally, I think design tests are useful, and I don’t resent doing them and I find the results very insightful. If you’ve never had a job in the game industry, you may not be able to afford to be as picky as someone with several years of experience because job opportunities are much rarer. But that doesn’t mean you have no choice in the matter. Keep that in mind when you’re balancing the need for a job with the amount of work a company asks you to do.

From Student to Designer: Part 3 – Cover Letters

As usual, my advice is specific to design and to seeking a more traditional job in AAA development, as opposed to breaking in as an indie, but most of it can be applied elsewhere. This is just my personal advice, so I recommend getting others to review your work for second and third opinions, and ultimately make your own decisions.

Part 1: Websites & Resumes
Part 2: Portfolios
> Part 3: Cover Letters
Part 4: Design Tests
Part 5: Interviews
Part 6: Entry Level Design Jobs 



I’m going to start off this article being honest – I actually don’t see many cover letters, and there’s really nothing that qualifies me to give advice on them. I think I write them well and often review them for my friends and the occasional student, so I am going to write about them anyway. I’m sure there are other articles out there that will contradict me, so, like always, try to use your best judgment!

A cover letter is the first thing most companies read, before they even look at the resume. It should be written specifically for that studio and the position you’re applying to – you really can’t get away with using the same cover letter at multiple places.  Cover letters should be about communicating important and necessary information, not for showcasing your wacky humor and unique personality. You can show off your personality in your portfolio, your projects, or even in interviews, but I would keep it out of your cover letter.

Of course, some people get away with wackier takes, like Tim Schafer’s infamous cover letter. But you are probably not Tim Schafer. Creative cover letters are more likely to turn people off because tone and humor are hard to pull off, especially with strangers..



Your cover letter is 350 words or less.

The reason I put this first is that the biggest mistake I see in cover letters is that they are too long.  So, so long. A cover letter is not the story of your life, it’s not you justifying why you deserve the position, or how much you like games, or why this is your favorite studio working on your favorite games.

Put that stuff in an “about me” section of your website or on your Linkedin profile or a blog post. I would not put it in your cover letter.

To repeat: your cover letter is 350 words or less. Don’t forget the “or less” part.

If your cover letter is longer than that, then start cutting. 350 words seems like an arbitrary number, but really it’s slightly longer than a traditional print page (250 words) so I am giving you guys some leeway. Obviously, if you are over this word count that doesn’t mean you’ve made a grave error – just that perhaps you need an editor. If you are seriously over this number than I think you should stop and re-read this article before committing to such a grave sin.

Everything you put in your cover letter should have a purpose. Every sentence should be delivering new and relevant information to a potential employer. Everything else can be cut.

350 words. Remember that!

Now that this is out of the way, I can get to the bulk of my advice.



There are a few key things I think you should have in your cover letter.

  • Greeting
  • What job you are applying for
  • What makes you qualified for the job
  • How YOU can bring value to THEIR company
  • Where they can find more information
  • Sign-off

That is, incidentally, the formula I use and recommend for people when writing a cover letter. I make each of these a separate section.

Dear Hiring Manager.

I am applying for [position] at [studio].

My relevant experience is [degree] and [shipped games]. I also have experience with [tool/engine] and have [relevant skill].

Your studio excels in [field/type of game]. I can bring value to your studio because I also have experience in [field/type of game], as you can see in [games/projects] in which I used [relevant skills].

I’ve [attached/submitted] my resume and you can find more of my work at [portfolio website]. Feel free to contact me with any questions.

Thank you for your time,

Now, this hypothetical cover letter is awkwardly worded if you were to just fill in the blanks and send it in, so I don’t recommend that. Instead I think it’s very useful for a rough draft. Lets take apart each section.


“Dear Hiring Manager,”

Use a person’s name if you have one – maybe from a business card, from a career expo or networking event, or from browsing Linkedin. If you don’t have a name, I would go ahead and use “Dear Hiring Manager” or “To Whom It May Concern”. Those always feel old-fashioned, but I haven’t found a better alternative.

Don’t overthink this. Definitely don’t misspell someone’s name or address the letter to the wrong person.

What Job You Are Applying For

“I am applying for [position] at [studio].”

This should be one of the first things you write. It tells the reader why you are writing them so they can immediately pull up the job listing, or pass the cover letter on to the person handling that position, or even to just put your email in context. You really only need a single sentence to get this across.

You should know the job title you’re applying for at that company – you get this from the job posting.  If you have to, I would use Linkedin to find the proper title. If you are applying without any open positions advertised, you could write something like, “I am applying for a position in the design department at [studio].” I would not apply to more than one position at once, except at a large publisher that usually fields applications for multiple studios.

(Unless you’re experienced, I recommend sticking to applying to open positions. Otherwise I hope you have a lot of free time on your hands.)

Sometimes it’s good to also mention location –  large publishers have many studios, so it’s important to name the specific studio and not just the parent company (Sony vs. Sony Santa Monica). Most of the time you’ll be sending your resume and cover letter to that specific branch, but if you are applying to an international job – where you, for example, live in the US and are applying to a job in France – it’s might be good to be clear about your willingness to relocate and so they don’t think you’re applying without realizing the distance involved.

What Makes You Qualified For the Job

“My relevant experience is [degree] and [shipped games]. I also have experience with [tool/engine] and have [relevant skill].”

A translation for this is, “I can prove that I read and understood the job description.”

I fill this out by going to the job posting and writing down all the key words. Most postings are great about detailing them out with bullet points and letting you know which details are necessary skills and which are supplemental skills that are nice to have. I would mention as many of those necessary skills as possible here. If the job is looking for a C++ programmer with experience in networking and mobile development, this is where you;d say, “I have extensive experience with C++ in networking and mobile development.” Of course, only do that if it’s true!

Wherever possible, I would give specific examples – such as shipped games you’ve worked on, certifications, or degrees. Just make sure that it’s relevant to the specific job you are applying for.

How YOU can bring value to THEIR company

Your studio excels in [field/type of game]. I can bring value to your studio because I also have experience in [field/type of game], as you can see in [games/projects] in which I used [relevant skills].

This is the section where I get a bit more free form. This is where I show how my interests and the studio’s interests align. Think of it as your way to show them that you are valuable specifically to them by telling them what YOU can bring to the table.

This is also where you could lay down a little flattery. Not a ton, mind you – no one wants to hire a rabid fan. But it’s nice to let the studio know that you are applying to THEM because THEY are your ideal place of employment (rather than just one studio on a list of 50 that you are writing cover letters for…). But I would rather you be honest about your interests than lie, so if you’re applying to a company that only makes sports games and you don’t like sports? Don’t lie about that. I would just neglect to mention it (though, I probably would opt out of applying in that case).

If the studio focuses on narrative games and that is why you are applying, say that, and show them you experience in this subject. If the studio focuses on multiplayer games, hype up your experience in multiplayer level or system design. If it creates free-to-play iOS games, talk about that. I would make it clear that your passion and goals as a developer is an ideal match with the direction of that studio.

Fro example, While above in qualifications you may have written, “I have level design experience in the Source engine,” here is where you can expand to say something like, “I’ve created several multiplayer maps for Team Fortress 2, focusing on asynchronous competitive gameplay.  I would love to bring that knowledge over and continue developing similar experiences on Evolve.” Here, I am showing that I understand the nature of the position, have knowledge about (and admiration for) the types games the studio makes,  and show that this position is part of my career goals (and not just a last-ditch desperate attempt to land a job!).

Whenever I’ve written cover letters, this is the section that ends up being the longest.

Where They Can Find More Information

“I’ve [attached/submitted] my resume and you can find more of my work at [portfolio website]. Feel free to contact me with any questions.”

This is called a “call to action” in creative writing. Once someone has your cover letter in hand and has read it to the end, tell them what to do next. This leads people to find out more information – your resume, your portfolio, your projects. Make it inviting for them to respond – but don’t beg!


“Thank you for your time,

This is simple. Don’t overthink it. You can go ahead and use exactly what I just wrote up there, or whatever your favorite variation is. I don’t think you should sign off with, “Love,” but you get the idea.



Many of the cover letters I see and proofread for friends or others who ask the favor seem to suffer from a few main problems. I wrote them down and canvassed a few other people who have experience looking at cover letters to get an idea of what the common mistakes are. There are probably more than the ones I listed, and some of them may not be too big of a deal with some people.

  • Too short – This is rare, but I have seen it. Usually it means either you don’t have enough experience (so you have nothing to talk about), or you just don’t know how to market your skills.
  • Too long – much, much too common. Do you remember what I said about 350 words? If it’s long, I hope there’s a reason.
  • Not being specific – this reads as a generic letter that could be sent to any company, and makes me think you don’t care about this specifiposition. You wouldn’t (shouldn’t!) do this on a dating website, so don’t do it here.
  • Being too specific – reads like an FBI brief!
  • Not talking enough about your qualifications – says you don’t value yourself and what you have to offer. Like I mentioned before, think of the cover letter as an opportunity to market yourself.
  • Talking entirely about yourself non-stop – This makes me think that while you value yourself, you don’t actually know much about the company. Again, think about how you can help them and try making that part of the cover letter.
  • Applying for more than one job – I recommend making one cover letter for multiple open positions because to me it implies you are either unfocused or desperate for a job. I am sure there’s exceptions but I’ve never seen a justification for it.
  • Applying for a job you are clearly unqualified for – This tells me you don’t follow instructions. Unqualified really means you are a junior level person and apply to a lead position, or you are an artist applying to a programming job. There’s a balancing act here between imposter syndrome and the Dunning-Kruger effect that only you can answer.
  • Applying for a job you’re qualified for, but not communicating this – Try looking at that job posting and make a Venn diagram of “what you know” and “what they want”. I would put any items that overlap into your cover letter.
  • Talking about your passion for games, how young you were when you started gaming, how much you like games, etc.I think some people appreciate this, but I (and others I talked to) have seen whole paragraphs dedicated to this. Loving games isn’t really a relevant qualification for making games – it’s a given.
  • Being jokey, tongue-in-cheek, self-deprecating, or writing a “unique” letter. It can be hard to get jokes across in such a short letter, and harder to entertain an unknown stranger whose tastes you don’t know.
  • Fawning over the studio like a fan rather than a peer – Making games is a job – it’s work, and sometimes it’s hard, frustrating, and imperfect. Hero worship for a creative director, or being the world’s biggest fan of a game, sets off a red flag for me that you may not be objective and critical of your work or your peer’s work. If you want to mention it, its a fine line to walk – but I do know a lot of people who were fans of a studio’s games before they started working at that studio.



That’s it. That’s all my advice – and obviously it’s advice and not a formula for success.

Cover letters are stressful because every single one is unique and there aren’t a lot of examples out there.  Once I started treating cover letters like technical documentation, it became a lot easier. Since every cover letter is context sensitive, I recommend finding at least one buddy who will help proofread for you – not just to catch spelling errors, but also to gut check whether your cover letter and the job description seem like a good match. Remember to keep it simple, keep it short, and keep it to specific and relevant information.