There are thousands of people out there looking for work. A couple of weeks ago I got a note from one of them.<\/p>\n\n\n\n
His name was Kyle. He wasn\u2019t asking for special treatment or an inside track\u2014he just wanted some advice from someone with experience in game production. How did I think about the job of producing? How do I measure the difference between a good producer and a bad one? What are the most important skills to develop?<\/p>\n\n\n\n
It\u2019s a huge topic. Frankly, I didn\u2019t want to go down the rabbit hole with him. But I also didn\u2019t want to just blow him off\u2014I wish I had had better advice and mentorship in production early in my career. So I offered that, rather than trying to sum up the discipline in a pithy email, I would share the interview questions I use for producers and explain why I feel they are important and relevant.<\/p>\n\n\n\n
About two hours later I got a message back. It was pretty simple. It said, \u201cI don\u2019t mean to bother, but just wanted to note that this was most helpful email that I have ever received.\u201d It inspired me to start a blog.<\/p>\n\n\n\n
I\u2019ll share my producer interview questions here in two parts, in hope they help people who, like Kyle, want not just to get the job, but to do it well once they have it.<\/p>\n\n\n\n
First, a note on my interview process. I use a standard question and notes format. I store it in Quick Parts in Microsoft Outlook. At the beginning of every interview, I create an email to myself. I put the candidate\u2019s name and the open role in the subject line. In the body of the email, I type a keyword, and the full interview outline is automatically inserted, including question and answer format, spaces for analysis and commentary, and lists of \u201cvirtues\u201d that I think are important (things like Ownership, Player Obsession, Singular Joy in the Work\u2026). From there I review the candidate\u2019s resume and write in a couple of specific questions related to their past accomplishments or interesting challenges they faced. I usually finish the interview, hit \u2018send,\u2019 and my notes drop into an email directory for easy reference during a debrief.<\/p>\n\n\n\n
For my questions, I almost always use the ubiquitous, \u201cTell me about a time\u2026\u201d format. I am almost never looking for what a candidate would do in a situation, almost always what they did do as a matter of practical experience. I\u2019m not that interested in hypothetical questions or situations, since they convey a lot less information than actual behavior in a real situation. If you\u2019re unfamiliar with this interview style, I highly recommend a quick Google search on \u201cBehavioral Interviews\u201d\u2014it\u2019s a 30-minute investment that will 2x your interview performance.<\/p>\n\n\n\n
In the questions below, \u201cTime\u2026\u201d is just shorthand for \u201cTell me about a time when\u2026\u201d<\/p>\n\n\n\n
This is almost always my first question. It\u2019s kind of a warm up, but usually produces specific topics I can follow up on later in the interview. Importantly, it conveys three big things: 1) experience from the candidate\u2019s past that indicates they\u2019ll be successful in the job they\u2019re interviewing for, 2) their understanding of the role, and 3) their ability to distill their experience into relevant highlights. In some ways, point three is the most important to me, especially because the job of a producer is often to summarize issues to stakeholders in order to draw out advice or a decision. This question tells me about the candidate, but also about how they communicate and distill, hugely important skills for a producer.<\/p>\n\n\n\n
I like this question because it quickly reveals practical production experience and ownership. It tells me about a producer\u2019s real-world process for defining, committing to and achieving goals with a team. An early mistake in every producer\u2019s career involves committing to a finished feature only to learn later that the developer meant something like, \u201cthe prototype will be finished,\u201d or \u201cI\u2019ll get it working but not integrated,\u201d and that that there\u2019s a lot more work to be done before work is stopped on the feature. They might still need to capture notes, address feedback, integrate art and fix bugs in order to fully deliver. The actual finished feature often takes 3-4x more time than the original estimate.<\/p>\n\n\n\n
Every experienced producer has grappled with the \u201cdefinition of done\u201d problem. Everything you produce will come together in phases. For some developers, \u201cdone\u201d means simply that their part of the work is done. For most players, \u201cdone\u201d means the product has shipped and they\u2019re playing it. There\u2019s an ocean of difference between the two. A producer\u2019s job is to commit to an outcome, then work with a team to deliver that outcome. As a producer grows in their craft, they are trusted with larger commitments over longer periods of time, beginning with assets and small features delivered in days, often growing to massive games or game franchises delivered over the course of years. But one thing never changes: to be successful, all parties need to be aligned on the intended outcome.<\/p>\n\n\n\n
Good answers to these questions tell me that a producer understands how to break a large task down into smaller phases, then track progress against those phases. Commonly, work will begin as a technical prototype, then have art integration, then design tuning and balancing, then animation and VFX, integrations, then final polish, bug fixing and release.<\/p>\n\n\n\n
I love when producers define and give names to each of these stages as a way to convey to their teams (and stakeholders) exactly where production stands on each effort. For something like a UI screen, the phases could be something like, Clickable Prototype, then Art Prototype, then Functional In-Engine, In-Engine Art and VFX, Final Polish, And QA Complete. If a producer has a well-conceived production framework for these phases, it\u2019s a lot easier to measure progress.<\/p>\n\n\n\n
If you\u2019re not doing it already, think about how you define phases of completion for the features and content you\u2019re producing. Who\u2019s involved at what stage, and how do you define success with each increment? If you can sketch out all your phases up front, you\u2019ll do a much better job of staying on schedule, and you\u2019ll likely see very early how one developer\u2019s six-week estimate was hopelessly optimistic if you actually want to produce something you can ship.<\/p>\n\n\n\n
Producers aways have to predict dates for things they\u2019ve never produced before. For time estimates, they usually rely on members of their team to estimate their tasks. But if you\u2019re relying on task estimates of others to build a schedule, what happens when someone falls behind? Does the whole enterprise fail?
A common answer to this question is something along the lines of, \u201cI get feedback from everyone involved, then add 30% contingency.\u201d But is that 30% just degree of uncertainty, or is there real work filling that space?<\/p>\n\n\n\n
On WWE2K, producing characters was profoundly complex. For any given superstar there is a head scan, multiple rigs, a hair model, a body model, gimmick, skin textures, shader maps, sweat maps, physical simulations (for swaying cloth, flowing hair, etc.), hundreds of moves and much, much more. If you added time estimates for each of those tasks together, you would not come close to the time it takes to build out a character. If there are different departments and dependencies, there\u2019s time involved in handoffs and approvals, plus lag time while one task is finished before the next one can begin. There\u2019s integration time, in-game tuning, testing, polish, feedback, revisions\u2014all of which comes to way, way more than 30%.<\/p>\n\n\n\n
So really, this is a question about ownership. When I ask it, I\u2019m trying to understand how much the candidate feels responsible for delivering product value, and how much they understand all the downstream tasks to deliver a feature or piece of content, vs. how much they\u2019re thinking about assets or components that someone else will assemble into player value.<\/p>\n\n\n\n
Releasing early to players is hugely valuable. It forces you to hone and polish your game for players who have lots of options vying for their time. It shines a light on the large volume of work required to move a game out of production\u2019s \u201ccommunity theater\u201d realm where flaws are tolerated and competition with other games is non-existent.<\/p>\n\n\n\n
This question helps me understand whether a candidate understands the difference between producing an interim\/QA build for internal use vs. a release-ready build that has to meet a high standard of scrutiny, and is subject to the risk of a bad player experience that damages the game\u2019s reputation. Producers with a \u201crelease mindset\u201d are rare, and super valuable; this question tests for that.<\/p>\n\n\n\n
A basic answer to this question would focus on QA and playtesting as the mechanisms for readiness. Most producers understand that a public build requires more QA and stability. Public builds also require attention to edge cases, non-primary user paths, caveats and known issues that keep users away from known pitfalls. Public builds may require lockouts preventing users from accessing content that marketing teams don\u2019t yet want revealed.<\/p>\n\n\n\n
While QA and testing are important, though, with this question, I\u2019m really looking to learn about a producer\u2019s relationship with the development team. In addition to all the process brought to bear AFTER a candidate build has been created, I\u2019m listening for a producer\u2019s process in getting to that build to begin with. To any producer with experience, the process of creating a build will be highly familiar: most developers work right up until their deadline. There can be scores of last-minute check-ins across the team. Builds are broken as a rush of new code and content is integrated, often with chaotic results.<\/p>\n\n\n\n
So with this question, I\u2019m looking to understand how an expert producer works backward from delivery dates. How do they impose deadlines, cut-offs, triage and approvals. What\u2019s their process for critical features? Do they know the highest-risk areas of development, and do they have a process for shutting them down early in order to drive stability\u2014progressive lockdowns, buddy check-ins, clear priorities?<\/p>\n\n\n\n
The perfect answer to this question starts with, \u201cEveryone checks in at the last minute\u2026\u201d It tells me not only that the producer has managed a closing process in the past, but that they understand the need for one.<\/p>\n\n\n\n
I\u2019m always surprised when a candidate struggles with this question. Working across disciplines to produce a playable result is the core of the producer\u2019s job.
I used to ask, \u201cHow would you produce a powerup?\u201d and mostly got the same result. For me, a powerup meets the definition of complex and interdependent because it usually includes, a 3D element, visual and audio effects, UI interactions, code and data representing in-game behavior, editor placement and effect on player status. Sometimes powerups with inventory or AI systems. Powerups, it turns out, interact with all kinds of engineering, asset types and player behavior.
I use this question to calibrate a producer\u2019s seniority. Early in their career, most producers concentrate on one asset or discipline type\u2014often producing art or animation assets with few direct dependencies on code or gameplay. Later, producers take on more entangled tasks\u2014things that affect gameplay or UI, and require multiple disciplines to deliver the full feature.<\/p>\n\n\n\n
A candidate\u2019s answer to this question usually tells me how much of a game experience they have been responsible for. Their answer also conveys a lot about organizations they\u2019ve worked within, their ability to manage through influence, or construct strike teams to achieve a player result. I\u2019ll learn if they are trained more in departmental thinking (old school), or agile, cross-functional production (more desirable).<\/p>\n\n\n\n
A great answer will always focus on value delivered to the player. \u201cI produced the smoke grenade for the last FPS I worked on. It enabled new kinds of close-quarters and assault gameplay. It touched almost department on the team, from gameplay engineering to VFX, audio, AI, UX, modeling, layout and encounter design.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"
There are thousands of people out there looking for work. A couple of weeks ago I got a note from one of them. His name was Kyle. He wasn\u2019t asking for special treatment or an inside track\u2014he just wanted some advice from someone with experience in game production. How did I think about the job […]<\/p>\n","protected":false},"author":1,"featured_media":56,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-container-style":"default","site-container-layout":"default","site-sidebar-layout":"default","disable-article-header":"default","disable-site-header":"default","disable-site-footer":"default","disable-content-area-spacing":"default","footnotes":""},"categories":[8,7,10],"tags":[],"class_list":["post-31","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-leadership","category-teambuilding","category-virtues"],"_links":{"self":[{"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/posts\/31","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=31"}],"version-history":[{"count":8,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/posts\/31\/revisions"}],"predecessor-version":[{"id":82,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/posts\/31\/revisions\/82"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/media\/56"}],"wp:attachment":[{"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=31"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=31"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=31"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}