Interviews

I'm really fascinated by the interview process. Hiring the right person is possibly the single largest impacting factor on company culture. Almost by definition, good companies are made up of excellent employees.

A good company--especially in video games--will always be doing things to disrupt the market and innovate. Market disruption and innovation doesn't come cheap: it requires passionate, creative, and very collaborative team members. Employees that have these characteristics are constantly hungry to achieve and use their talents and energy towards creating incredible products. Good employees like this should be hard to keep a hold of. If you're not competing for their employment with another company, you're probably competing with the employee themself from going off to do their own thing.

Sub-par employees are the opposite: they're rarely thought of when looking for a high-performance role outside the company, and they are frequently satisfied with their environment. The end result for the company is that excellent employees will eventually leave for different, better paying, or more interesting jobs, while the company is left with the mediocre employees that aren't driven enough to do anything but stay in your company forever. 

To me, it seems that with every mediocre hire there's a permanent spot in your company that is occupied by someone who could have been an excellent employee. And with every excellent hire it's only a matter of time before they move on to something else. The only employees driven enough to leave are your excellent ones, and with every hire you run the risk of hiring a mediocre employee who will stay forever. It seems all companies run into the problem of 'mediocre decay'.

That being said, keeping your high-performing employees isn't an impossible task, but that discussion is for another post.

The thing that fascinates me the most about the interview process is how much thought we put into it while knowing that it's nothing like a job at all. An interview tests a candidate's prepared responses and, at best, tests their ability to think quickly and improvise thoughtful answers they hadn't pre-meditated. Yet it's still remarkably easy for poor candidates to appear the best fit in this environment. Candidates who are stubborn, rude, have low work ethic, or sub-performing can be considered top candidates after an interview process. It's not until a few weeks into the job that it becomes clear that this person was either a fantastic hire or a complete lemon. 

As a result, I always find myself reading any article touting information of good questions to ask potential hires. I can't get enough of it. As I find more articles, I'll add them to this post to start accruing a collection.

The 7 Questions Recruiters At Companies Like Amazon And Spotify Wish You Would Ask

Three Habits Of The Best Job Candidates I’ve Ever Interviewed
Never Take A Job Before Asking These 10 Questions
https://www.inc.com/jeff-haden/5-job-interview-questions-that-reveal-what-a-candidate-has-really-accomplished.html

Staging is Important.

Bug fixing data-driven gameplay can be challenging, and Chris and I have put a lot of time towards developing a process for the many stages that are needed to test before pushing to the world. To make things more complicated, Bold Moves will pull data from one of two servers depending on the kind of build that the game is published on.

For a while, our pipeline consisted of DEV, TEST, and PROD. The problem that arose from this is that we didn't have a safe environment to test data on the production server before releasing to the world. Each of these stages have their own manifest file, and without STAGING we had to test pre-live builds by manipulating the actual data that consumers were using in a way that also wouldn't disturb them. 

Very bad practice. 

At the time, TEST was pulling double-duty: it was for testing data in preparation for consumers as well as new features and back-end functionality. It was an appropriate test environment; TEST data rarely changed compared to DEV, and it was mostly the features that were intended to become live. The biggest problem with this is that TEST is on a different server from PROD altogether. We couldn't guarantee that all the necessary assets were in place before the new data hit live.

We've built in a few compatibility checks to the data that prevents the game from downloading out-of-date data, which allowed us to get around the problem for a while by preparing builds that were on a different version number on PROD. Ideally, Bold Moves development will reach a state where we rarely push new updates and deliver content entirely through server-side data. Without a change in code, we would have been unable to test new data on the Production server without consumers also seeing this data.

Data Driving Tools

Bold Moves is a data-driven game, which means that the content is completely separate from the code base and can be loaded in a separate step. It does some incredible things for us, as we're able to dynamically change level content and perform A/B testing just by changing a few files on the server that all the devices download from.

Currently, I'm the only person capable of managing the data on the server, and what data each device downloads. Anytime data needs to change on the server--whether it's test, dev, staging, or production data--I have to be there to make sure that it happens correctly.

I really hate processes like this, where one person is the only one capable of making changes to the game, so I've been spending the past few weeks developing some publishing tools to allow other people to make changes to data, as well. This next launch, Chris is going to do all the data management and give me feedback on how to make the tool more intuitive and user-friendly. The hope is also that we'll be able to identify the most important missing features of the tool and put time towards that, as well.

Lame Reward

Over the past year, I've helped develop and launch Bold Moves, a match-3 game for the Oprah Winfrey Network. It's been a really tremendous experience, and I've learned a lot about freemium models and data-driven gameplay. Bold Moves has been a huge success for the studio, and is actually RED's largest and most profitable game to-date.

As Bold Moves ramps up in success, it attracts more attention of people inside RED and at OWN. This isn't terribly surprising, but as more people come onto the project it feels like I have less and less control over the direction the game takes, and even what I spend my own time on. 

It's both flattering and frustrating. Chris and I worked to build this fantastic game that RED has never had experience doing before, and it works. Now that it's proven successful, higher-ups want to steer it in a direction to make it even more profitable, but don't want to "shake things up" by moving Chris or I off the project. 

Keeping us both on the game is a really lame call. First, taking control from the team actually developing the project is the biggest "shake up" you could possibly do. Chris and I have a history of making excellent games, and I feel like our reward is to stick around on one of those games without any say in it. Either he or I would be much better utilized in any one of the many incoming projects for RED. Second, there's really not that much to do on the game presently, and all the remaining work are things that a new hire could pick up perfectly well and still be excited by.

Highly creative team members require a lot of maintenance. They are like a fire, and you need to keep fueling that fire with exciting things to work on. I keep getting passed up for working on other projects because I did such a great job on this project that I can't be taken off. That's not much of a reward for doing great.