Hiring Managers: Vetting Game Programmers

So you're in that blue sky brain-storming session and there are a ton of awesome ideas up on the board, and then someone says, "This is GREAT! Now we need someone who can make it work like that." Yep, you need a programmer. And not just any programmer. You need someone who can push the envelope, work with all the teams and fit into and grow with your company's culture. That's the moment your Quest begins . . .

There's a lot of "ebb 'n flow" these days and a lot of open jobs. A lot of people are getting hands-on experience, thanks to the ease of making small social games. Their work is easier to see but harder to vet. There are programmers at big companies whose projects are either ending or whose companies are downsizing (or closing), but there may be relocation issues that have to be considered in addition to salaries.

To increase the odds of making the best hire for your company, you want to develop a basic "vetting" system that looks at traditional and non-traditional aspects of your potential new programmer.

Step 1: The Job Description

Before you write the job description, be sure you have a good understanding of what various job titles mean. Terms like developer, programmer and engineer aren't always interchangeable. A QA person might be called an engineer at one company, while developer might refer to someone other than a programmer. Some programmers prefer engineer because it sounds less like a drudge position. If need be, include a sentence or two that describes what the title means at your company.

Figure out what you want your new hire to do, then write a job description that clearly states you’re required and preferred criteria. Aim for something between "as long as you're breathing" and "must have a Masters Degree in everything." (Hint: It's pretty easy to spot a job req that's been customized for someone you've already decided to hire.)

Here are some things to look for:

Let candidates know if some kind of testing will be administered. If you have questions about the legality of testing, check with your HR department, and if they don't know, get the info from someone who does, like your state's employment agency. Surprising an interviewee with an on-the-spot test (the formal kind) can be grounds for action, and not the good kind.

Be clear about your interview agenda. Will candidates be asked to undergo both "personal" and "technical" interviews?

Do you want to see a demo of the candidate's work? Do you want to see it online by yourself? Ask for a CD or URL. Because of proprietary software and NDAs, be willing to look at open source work and/or game modding.

Does your formal application allow for an attached resume, or will the candidate be required to fill it out? Will the candidate be asked to provide a salary history? Letting interviewees know this in advance saves you time and helps reduce the normal anxiety that comes with interviewing. (It also tells you if the candidate can read and follow directions.)

Step 2: The Resume

Read the resume before the interview. This may sound sort of "duh" but looking at the resume in front of the candidate sends a message (intentional or otherwise) that this interview is either inconvenient or a pro forma exercise so the company can hire the person
it REALLY wants. Reading the resume in advance gives you a chance to come up with specific questions.

Check out the companies listed on the resume. How long has the candidate worked at the past few companies? Are any of them start-ups? Do you really want someone who has moved quickly up the ranks and name-drops like crazy but has no real experience?

Step 3a: The Interview

If someone in HR is doing the initial interview (other than having the candidate fill out paperwork,) be sure you've reviewed the job reqs with that staff member, and provided some initial questions you'd like them to ask the candidate. Letting someone with no technical background and/or real industry knowledge conduct the initial interview might let a fast-talking candidate in the door and a good one get away.

Everyone who's participating in the interview should be prepared (i.e., has a copy of the resume and has seen the website or CD). If you're including "peer" interviews for the candidate, be sure your staff knows that their job is NOT to scare the candidate way.

You know the drill: be prepared, be prompt (and if you might get called away to an emergency, let the candidate know before you start the interview), don't take calls (unless there's a pending emergency). Be focused and ready to listen. As a courtesy, if you're deathly ill, stay home and let a colleague conduct the interview, or make arrangements to do it via Skype or some kind of video conferencing.

Having a member of the team with whom the potential hire will be working, preferably the team lead, as part of the interview process is always a good move. While there are many skilled programmers who can fill your job, getting one whose personality meshes well with your other programmers is always a bonus and in some cases, a must.) Remember that these people will be working very closely with each other, often in frustrating circumstances (the dreaded crunch time, for instance), and an argumentative or disruptive team member can cause a hit to productivity. Personality and work ethic is just as important as skill set, especially when you've got a small team, a tight schedule and no money to spare.

Step 3b: Interview Testing

Assuming you're cleared for testing, use simple programming or logic tests. Asking very specific questions, like hex and terminology definitions, isn't the most effective way to evaluate a programmer’s ability to code because rote answers don't tell you how the candidate programmer THINKS.

Recent grads will probably be able to answer "arcane" questions because the info is fresh in their heads but is that what you really need? Good programmers like to solve puzzles, riddles and mysteries rather than apply canned solutions. The right candidate will have some basic problem-solving skills in addition to specific programming knowledge.

Propose a simple programming issue and ask the candidate how s/he would handle it. Maybe a brain teaser or a suggestion for a modification to your product, which has the added benefit of showing you how well the candidate prepared for the interview. A good type
of coding question is one that has several answers; ask your prospective hire to give you the most optimized solution. You can quickly gauge how well he/she thinks and solves problems based on the answer. Someone who consistently picks the most obvious but less optimized answers is good for entry level positions, but if you're hiring for senior positions, you'll want people who can think on their feet, understand the need for optimization and have good reasoning behind their choices.

Here's an example of a good question:

Every number between 1 and 100 has been inserted into an array of 99 integers in random order, with a random number missing. What's the most optimized and memory-efficient way of figuring out which number is missing?

A weak answer would be to create 100 flags, then loop through the array and log each number, and subsequently loop through the flags to find the missing one. A stronger answer would be to loop through the array and add them all up into a single integer, then subtract the answer from 5050 (the sum of all the numbers between 1 and 100). An even stronger answer would be to sort the array, then loop through until a number gets skipped.

If you want to ask technical questions, avoid asking hypotheticals like what types of inheritance or global variables appear in a CPP file or polymorphisms or singletons in C++. Instead, present actual situations that are relevant to your product or project (unless, of course, any of those other examples ARE relevant. Bear in mind that the simplest code is, more often than not, the best code. A programmer who loves to pepper the code with
unnecessary methods like 'mutable's and 'goto's might not be the best candidate. Likewise, don't ask questions that are overly complicated for your code base. Unless you regularly need inline assembly code, don't ask the hire to describe how to unwrap loops or other overly complicated questions. While it's a great indication of general knowledge, it won't tell you if they'll do a good job.

In some circumstances, you may be looking for someone who can not only move forward with a project's code but also knows how to deal with legacy issues in a manner that doesn't involve stopping the entire project and starting over from scratch. It's great when the candidate sees this situation as an interesting challenge but you want to avoid the candidate who claims to be able "fix anything."

Step 3c: Interview Questions

Ask the RIGHT questions. Hopefully, the combination of a well-crafted job description and vetted resume has weeded out candidates who aren't right for the job.

Does the candidate use/play your product regularly? If you make MMOs, you'll be able to determine the level of immersion and investment pretty quickly. If the candidate gets that glazed look and launches into a Very Detailed Account of her avatar and the last raid, that tells you something, too.

"Beware the lone programmer in a room" is an old industry adage that still rings true. You want someone who will fit into your company's culture and actually likes working with other people. Does the candidate seem like someone who will thrive in a high stress team environment (if that's what you've got) or does the candidate seem like someone who's more interested in showing others "how it's done."

Consider asking some off-the-wall questions like, Do you prefer cats or dogs? Cake or pie? Summer or winter? And why? An industry veteran interviewing a programmer candidate said, "Tell me a joke." The stunned candidate replied, "Oh. Do you want a funny one? I didn't really prepare anything." That told the interviewer what he needed to know about
the candidate's ability to think on his feet.

Ask about a "hot" programming topic that's making the rounds on industry boards and at conventions. Is the candidate passionate about one side or the other? Dismissive? Baffled? (Hopefully the candidate will not say, "Well, does that really have anything to do with this job?") Having a sense of humor is actually pretty important in our industry because it
reduces the possibility of melt-down at the worse possible moment.

Ask candidates what they love about programming. (Hint: "An easy way to earn a living" probably isn't what you want to hear. "I love to solve problems" or "I like to make great games" is better.)

What's the biggest thing the candidate worked on that didn't ship? Do they have any idea why it didn't ship? Watch out for indications that the candidate thinks failure was other people's fault. One of the tenets of Agile Development is that failure by one unit is failure by all, so you don't want to hire someone who's more adept at finger-pointing that accepting
responsibility and proposing positive solutions.

Has the candidate worked in an Agile Development environment and if so, how was it? If it seems that the candidate felt it was intrusive, see if you can determine whether the system was poorly administered or the candidate just doesn't like to be interrupted or told what to do.

What was the biggest challenge the candidate has faced as a programmer so far, and how did s/he solve it? (For female programmers, gender bias may be the biggest issue so be sure you stay within the boundaries of what can and can't be asked legally.)

Ask question(s) that give you a sense of how flexible the candidate is, how willing to try new approaches, take suggestions and explain solutions. Odds are you probably won't be happy with some hot shot who thinks that everyone else is too simple-minded to understand what he does. (In fact, sometimes this is a red flag that the programmer might not be so good at
building strong foundations or accepting responsibility when fixes don't hold together.)

If you decide to review the candidate's demo in person, ask what specific portions s/he handled. Obviously, with a small app, it's probably "all the programming" but if it's a big game, the programmer was probably part of a team. Ask about how collaborations worked and whether the programmer's suggestions for game play improvements were considered. Avoid the programmer who says, "Oh, I write the stuff but I don't play the game."

Here are some questions on the "lighter" side:

Although there's no single magic formula for hiring the best programmer, you've got a lot of tools at your command that will give you a pretty good sense of which candidate has the right skills and is the best fit for your company.