The Producer Interview Script

The saying goes that if you want to find a prince, you should be prepared to kiss a lot of toads. That is not the situation we found ourselves in. Over the last couple of years, I have had the privilege of hiring for both senior and lead producer positions at a top-notch studio. We have excellent projects, mature teams, and seats at the AAA PC/Console table, which are are hard to come by these days. We sifted out all the toads pretty early.

Combine that with a notoriously challenging year in the game industry, with huge numbers of layoffs, and we had the pick of the litter. I talked to dozens of qualified producers over the last year and a half. Beyond being able to simply do the job, the question that always matters to me is how they do the job and what impact that's going to have on the chemistry of my team. To that end, I've developed a script that I work through in the course of an interview.

Let me be clear - these are not questions with correct answers. If you're asking candidates to reproduce what you already know, you're doing it wrong. Anyone who's been through multiple cycles of development is going to understand that production is not a process but a toolkit (that includes processes) for getting the most out of a team. Every team and every project is different. Going in thinking you already know how the team needs to work is a red flag. There are only a few questions in game development that always have a right answer (how to come onto a team, for example); everything else is more nuanced.

For those of you who have never interviewed with me, I like to set an agenda upfront. First, I confirm that this is still a good time to meet and how much time we have allocated; things change, and as long as everyone knows going in, we can reschedule or focus as needed. Second, I divide the time into roughly thirds - one third for introductions and backgrounds; one third for discipline questions; one third for candidate questions. This means that I'm only explicitly spending 20 minutes on production skills, although in reality, the entire interview is a skills test. Communication is critical to production; you have to demonstrate clarity, efficiency, and effectiveness with verbal communication, just like the resume needs to demonstrate that you have excellent written skills.

I like to put candidates at their ease by introducing myself, the project, and the role first. This serves a couple of purposes. One, it sets the level of detail for the conversation; if I can cover almost 25 years of game development and publishing in under 5 minutes, you shouldn't take 10 to cover your last role. Two, it establishes a common frame of understanding; if there are any red flags, we can get those out of the way up front and save everyone's time.

Wherever possible, I like to take a more conversational tone and weave questions into the natural flow of the conversation, but some candidates are more comfortable in the Q&A format, so we often fall into that. Oftentimes, we will cover topics organically, in which case I won't necessarily raise them as explicit points, even though they are part of the overall script. Usually, we won't get to all of these; if we don't get to many of them, that's a red flag - we should be able to move through a high-level discipline conversation pretty quickly.

1. Agile Vs. Traditional scheduling

One of the first things I like to ask people is where they fall on the agile/traditional scheduling spectrum. Most everyone these days hybridizes at some level - using more waterfall methods for longer term planning, while using agile for more short-term or day-to-day operations. Again, there isn't a right answer here. What I'm trying to understand is what assumptions and frameworks the candidate is bringing to the problem. For people who self-identify as traditionalists, I get into dependency tracking and Gantt charts. For people who self-identify as agile, I always ask about the Agile Manifesto.

It astonishes me how many experienced, self-identified agile producers either have never read the Agile Manifesto or aren't familiar enough with the values and the principles to have an informed conversation. This isn't about dogma; this isn't about memorization. I don't expect people to be able to cite the values on demand. But, I expect that at some point, if you're an agile producer, you've thought through how the Manifesto, its values and its principles, measures up against your own experience. If you're really committed to the discipline and to self-improvement (which is part of the agile mindset), then you should have at least asked yourself the question. It's not a disqualifier, but if you call yourself agile and you don't understand the foundational philosophy, that's a yellow flag.

Similarly, anyone who claims that there's only one true way to manage development is a red flag at this stage. You may have your preferences; you may have your successes; but, if you haven't seen enough of the industry to understand that there's more than one way to make games, you're not going to fit in here. We're looking for lifelong learners - people who will look into every scheme to see if there is something usable, something adaptable. A good producer knows that solutions come from everywhere.

2. Production Rituals

People have all kinds of experiences with production, so I try not to carry any assumptions into the conversation with me. One of the things that I'll do is to describe an abstract, generalized production cycle: the team agrees on a description of the work, the team commits to getting some portion of that work done in a specified timeframe, there are check-ins and progress monitoring, once the work is done, it is demonstrated to stakeholders, the team has a chance to review and change process, and then we're back to agreeing on a description of the work.

This is a necessarily clumsy framework. It is not truly agile; it is not classically waterfall. It could apply equally to week-long sprints or half-year milestones. The point of the question is to understand better how the candidate approaches production as work. The question is, "Where in this cycle can you save time and energy without sacrificing quality, and where do you spend that extra energy?"

Every part of the production cycle is important. Where a producer puts the emphasis in this is largely a personality test. People who emphasize the importance of the description are very different from those who emphasize the importance of the retro. Again, there are no right answers here. I'm trying to understand what kind of producer we're talking to and how they're going to mesh with the team. Someone who insists that monitoring and check-ins are the most critical thing isn't going to gel with a fail-fast mentality. Someone who puts all their chits on retros may run into issues with more vertical organizational structures.

3. Sprint Cycles

If I'm dealing with someone whose primary experience is not agile, I'll sometimes skip this one. The question is "Talk to me about the tradeoffs between 1, 2, and 3 week sprints." Again, there are multiple purposes here. First, I want to see whether the candidate has experience with all 3 or just a subset; this also will often speak to whether people have experience structuring production or are used to following established patterns. Second, I want to see how they conceptualize overhead and its relationship to the cycle.

While there aren't any "right" answers here, there are several wrong ones. I've had people insist that one week sprints aren't viable (in spite of the fact I've run them); I've had people insist that anything shorter than three weeks and you can't get meaningful work done (also bullshit); I've had people insist that anything beyond two weeks and you need a mid-point check-in (depends on the team). In general, it's not a good idea if someone asks you to compare three positions to completely invalidate two of them.

My experience is that time divisions are arbitrary. You can run one-day sprints. You can run hourly sprints. The overhead in agile always works out to be about 10% of the time. When you're running weekly sprints, you can manage your overhead in about half a day; when it's two weeks, it's a full day; three weeks, you need a full day and then some. By the time you get to 4 weeks, you might as well divide into 2 2-week cycles, unless you have really long sightlines. Again, most producers will understand that it's a tradeoff between how frequently you need to plan and how quickly you're making discoveries that might re-shape that plan.

A more nuanced/experienced producer will point out that different phases of the project may need different cadences. You may want to be in one-week sprints when you're prototyping core gameplay, for example, or when the team is very small. As the team grows, and the problem set becomes more stable, moving to two or three week sprints can give the team a sense of breathing room. Ultimately, the team needs to decide - either explicitly through conversation with the producer or implicitly through their velocity metrics.

My favorite answer was someone who pointed out that it is largely arbitrary, that different teams work different ways, but that the length of the sprint should be correlated to the width of the cone of uncertainty - the more unknowns in the terrain, the faster you need to recalibrate as they come into focus; the more well-known the problem set, the less frequently you need to adjust.

4. Design Pipelining

I may get some flak for this, but art pipelining is easy. You figure out how many stages your assets need; you figure out what each stage takes; you calibrate all of your IC's, and you math it out. Design pipelining is hard, particularly when you have creatives who don't deliver reliably or are stakeholders. So, the question is "How do you roadmap design work?"

There's only one wrong answer here, which is "I don't". Anyone who lets design run on their own clock is going to suffer the whims of outrageous fortune with some regularity. Design work may be nebulous and difficult to define, but it can be timeboxed, measured, and evaluated.

People who have dealt with difficult creatives will have a common toolkit - getting signoff, making commitments, managing change requests through cost tradeoffs, establishing phases and requirements of delivery. If you've been around the industry long enough, you've seen this, and it's not rocket science. You have to get people to make their deadlines. That's part of the job. If you're not comfortable nagging people, you're not going to be happy being a producer. If you can't have difficult conversations with people, you're really going to hate the job.

My favorite answer on this one was someone who managed to pull the perfect jiujitsu move on their creative director - yes, absolutely, we'll give you everything you want. You just have to tell us what order you want it in, and then we'll tell you how much will make it into the game. The horse trading is going to happen, but now it's between desire and reality, not between creative and production.

5. Team Structure and Team Size

These two tend to fall together a lot because there are certain thresholds that people cross where communication patterns need to shift for organizations to be effective. The core questions are "How do you like to organize teams?" and "What's the biggest team you've ever managed?" The temptation is to think that there's a right answer here, but there isn't.

On the team structure side, I want to understand how the candidate thinks about the work - what does it mean to define it, to commit to it, to evaluate it, to call it done? Is it asset-driven? Is it testing-driven? Is it gameplay-driven? There are many, many ways to build games. There isn't a right answer here, but there can be meaningful deltas between how the existing team does these things and how the candidate does.

On the team size question, larger is not necessarily better. We run an intentionally small team here. We're on the cusp between Indie/AA and true AAA. Our ambition is to be small, but mighty. Someone who has worked in large organizations may not understand that hiring someone is not the right answer for every need on a team.

The ideal answer takes into account that teams at different sizes work best in different ways. Small groups can move fast and rely heavily on organic communication. You start to cross thresholds at 12, 25, 50, and 100 where you have to make meaningful changes (there's no scientific veracity to those numbers, that's just my experience). A team of 100 people needs a different level of documentation and tracking than a team of 10. One solution won't fit all.

6. Team Health

This one used to be very different. A producer who couldn't read the room, who didn't do walkarounds, who wasn't using the physical space of the office to help motivate people, these pieces were so basic that anyone who didn't do them immediately got sifted out. In the fully remote context, though, none of this applies. So, the question is simple: "How do you monitor and adjust team health?"

Again, there are many right answers, but only one wrong one: "I don't." Producers need to own the health of their teams - you're responsible for the outputs of the team, but also the state it's in at the end of the cycle. Google forms are basically free and easy to set up. Producers should be doing skip-level 1:1's with their team on a regular rotation. There are various third-party sentiment tracking tools out there. It's not how you do it - it's that you have done it, seen the need for it, and found ways to meet that need.

My favorite version of this came from a server engineer I used to work with - he said that a good producer knows when to heat the team up and when to cool them down. For me, this is very much like game design - there's a productive tension under which the team works optimally. Too hard, everyone is frustrated and angry; too easy, people get bored and drift. Get the tension right and everyone is focused, committed, and aligned. The need to hit the deadline is a productive constraint because it makes priorities meaningful.

7. Planning Window

This one tends to come up very early for traditional scheduling producers - "What's your preferred level of granularity for roadmapping and at what cadence are you just bucketing?" One of the key tradeoffs for production is that time spent planning isn't time spent doing. Every time you have to re-plan, you lose a certain amount of time (not really - that time is neither lost nor valueless).

So, maintaining a schedule through phases of granularity is a common solution. For the next sprint, I want to know exactly what we're delivering (doesn't matter how long a sprint is; if this sprint is committed, as a producer, you need to understand what next sprint looks like). For the sprint after that, I'm okay with knowing a little less, out to about 3 months, which is the longest gap anyone should have with their partners - publishing or otherwise.

Other people like to have longer planning windows - out to a year isn't insane. As long as you're not wasting your leads' time making them estimate things that aren't sufficiently defined, anywhere between 3-12 months is a reasonable planning window, particularly if you scale by using milestones and mid-milestone drops.

People who don't understand this tradeoff are a red flag - they're not including production cost in their calculations. Similarly, people who insist on having detailed schedules 18+ months out, they're creating unnecessary overhead for their teams. People who can't plan out to 3 months are a liability - it's not that complex.

What I'm looking for here isn't a particular number - it's an understanding of the tradeoff between planning time and execution time and the ability to shift scales as needed to keep the scheduling sequence and project priorities intact.

8. Risk Mitigation Plan

This one often comes up organically, as we talk about scheduling or dependencies, but in case we haven't gotten to it, I like to ask candidates how they organize and manage a risk mitigation plan. Some people haven't; that's not necessarily a red flag. Particularly when interviewing senior producers, some people just haven't been exposed to the tool. For leads, that's more of a yellow flag.

Again, there are many ways to do this. The important thing for me is the collaboration with the leads. If the producer is trying to define risks without them or the team, or if they're pushing mitigation strategies at the leads rather than developing them together, that's another yellow flag. Ideally, people have a process for gathering risks from the larger team, not just the leads. Even better are processes that regularly re-score the risks by probability, impact, and severity.

It's not just the plan itself, here; it's also how the plan is used as a tool by the producer - are they thinking of it as a way to manage up? Is it a way to reflect reality to the team? Is it a filter for grooming the backlog? There are many productive ways to talk about risks with a team. This isn't about dogma; it's about communication and collaboration.

9. Conflict resolution

This is another one that had a different set of answers when we all worked in the office. In the fully-remote context, there's a lot more nuance to this, so it often comes up in the framework of the team health conversation - effective team health monitoring also means identifying conflicts that may not be immediately apparent or visible and helping to resolve them before they start becoming endemic within the team.

The key thing I'm looking for here is the cost-effectiveness (often time efficiency) for how producers are managing this and how much they've been able to adapt to the remote space. There are ways to do this that are both personally and collectively very expensive - managing through 1:1 dynamics in a remote context can multiply costs. At the same time, you can't neglect it. You need to know as soon as something starts going wrong.

10. Optimizing the team

Once you've got the team working - people are communicating, the work is getting defined, committed to, and completed - what's next? Or, as I'll often frame it, "How do you optimize the team for productivity?"

The key term here is "productivity" - how each producer defines that term is just as important as the techniques they put forward to get there. Do they rely on metrics? On personality? On crunch? Do they care about assets delivered, quality bar, user validation, stakeholder signoff, or something else? Do they bring any interesting/new/unique solutions to the table?

Again, this is really a personality test - there's no right answer. But, I know my team, and I know how they're going to react if you try to "optimize" them in certain ways.

And that's it. 10 topics. 20 minutes. Most of the time, we won't get to all of them. If we do, that's a good sign. Since I try to leave a significant chunk of the interview to candidate questions, sometimes we can cover these topics - as people ask me about current team size, for example, we can get into the dynamics of communication at different thresholds. Sometimes they come up organically as people describe their own experiences. Each interview is different.

But, when put together, this gives me a pretty comprehensive picture of how someone goes about the job of production. There's a lot of details I don't care about here - Jira vs. other solutions, QA relationships/philosophy, outsourcing, etc. We can get into all of that if they make it past the initial test.

This isn't perfect, by any means. It's idiosyncratic - it serves my purposes. But, hopefully, it opens up a window into what kinds of things people are looking for when they hire. We walked away from a lot of good producers - people who were capable of doing the job - because they didn't fit in other ways; they weren't going to mesh with the team; they were going to have to fight their organic way of organizing work to fit what the team had agreed to do, or some such.

There is a lot of common ground among experienced developers. If you've been through the cycles and you've shipped high quality products, you know the struggles. There are a lot of flavors of producer - beyond the standard product, people, process (which you would be surprised by how few people know) - and making the right team relies on being able to balance all of the elements. Much as agile won't solve your problems, but it will surface them, this is a lens that helps me to understand who I'm talking to relatively quickly. I'm sure it could be improved.