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’t asking for special treatment or an inside track—he 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?
It’s a huge topic. Frankly, I didn’t want to go down the rabbit hole with him. But I also didn’t want to just blow him off—I 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.
About two hours later I got a message back. It was pretty simple. It said, “I don’t mean to bother, but just wanted to note that this was most helpful email that I have ever received.” It inspired me to start a blog.
I’ll 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.
My Interview Process
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’s 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 “virtues” that I think are important (things like Ownership, Player Obsession, Singular Joy in the Work…). From there I review the candidate’s 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 ‘send,’ and my notes drop into an email directory for easy reference during a debrief.
For my questions, I almost always use the ubiquitous, “Tell me about a time…” 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’m not that interested in hypothetical questions or situations, since they convey a lot less information than actual behavior in a real situation. If you’re unfamiliar with this interview style, I highly recommend a quick Google search on “Behavioral Interviews”—it’s a 30-minute investment that will 2x your interview performance.
In the questions below, “Time…” is just shorthand for “Tell me about a time when…”
Q: Highlights from your past that prepare you for this role?
This is almost always my first question. It’s 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’s past that indicates they’ll be successful in the job they’re 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.
Q: Time you used a crisp phase definition to measure progress?
I like this question because it quickly reveals practical production experience and ownership. It tells me about a producer’s real-world process for defining, committing to and achieving goals with a team. An early mistake in every producer’s career involves committing to a finished feature only to learn later that the developer meant something like, “the prototype will be finished,” or “I’ll get it working but not integrated,” and that that there’s 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.
Every experienced producer has grappled with the “definition of done” problem. Everything you produce will come together in phases. For some developers, “done” means simply that their part of the work is done. For most players, “done” means the product has shipped and they’re playing it. There’s an ocean of difference between the two. A producer’s 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.
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.
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’s a lot easier to measure progress.
If you’re not doing it already, think about how you define phases of completion for the features and content you’re producing. Who’s involved at what stage, and how do you define success with each increment? If you can sketch out all your phases up front, you’ll do a much better job of staying on schedule, and you’ll likely see very early how one developer’s six-week estimate was hopelessly optimistic if you actually want to produce something you can ship.
Q: Time you built out a schedule based on task estimations from the developers?
Producers aways have to predict dates for things they’ve never produced before. For time estimates, they usually rely on members of their team to estimate their tasks. But if you’re 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, “I get feedback from everyone involved, then add 30% contingency.” But is that 30% just degree of uncertainty, or is there real work filling that space?
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’s time involved in handoffs and approvals, plus lag time while one task is finished before the next one can begin. There’s integration time, in-game tuning, testing, polish, feedback, revisions—all of which comes to way, way more than 30%.
So really, this is a question about ownership. When I ask it, I’m 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’re thinking about assets or components that someone else will assemble into player value.
Q: Walk me through the closing process you have used to get a build ready for public hands on or release.
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’s “community theater” realm where flaws are tolerated and competition with other games is non-existent.
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’s reputation. Producers with a “release mindset” are rare, and super valuable; this question tests for that.
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’t yet want revealed.
While QA and testing are important, though, with this question, I’m really looking to learn about a producer’s relationship with the development team. In addition to all the process brought to bear AFTER a candidate build has been created, I’m listening for a producer’s 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.
So with this question, I’m looking to understand how an expert producer works backward from delivery dates. How do they impose deadlines, cut-offs, triage and approvals. What’s 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—progressive lockdowns, buddy check-ins, clear priorities?
The perfect answer to this question starts with, “Everyone checks in at the last minute…” It tells me not only that the producer has managed a closing process in the past, but that they understand the need for one.
Q: Something you produced that was complex, with lots of interdependent parts created by different developers.
I’m always surprised when a candidate struggles with this question. Working across disciplines to produce a playable result is the core of the producer’s job.
I used to ask, “How would you produce a powerup?” 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’s seniority. Early in their career, most producers concentrate on one asset or discipline type—often producing art or animation assets with few direct dependencies on code or gameplay. Later, producers take on more entangled tasks—things that affect gameplay or UI, and require multiple disciplines to deliver the full feature.
A candidate’s 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’ve worked within, their ability to manage through influence, or construct strike teams to achieve a player result. I’ll learn if they are trained more in departmental thinking (old school), or agile, cross-functional production (more desirable).
A great answer will always focus on value delivered to the player. “I 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.”
