4/4 Series on Vetting Game Programmers: Testing and the Interview

I mentioned in my last article but it's really important that you do a little bit of research and carefully read the candidates resume before you begin the interview.

It's basically just common courtesy for you to do a little bit of extra research on someone that you're going to meet for a job interview. After all your literally inviting them to join your family if you like them and therefore you want them to like and respect you too.

So take a moment, with a separate sheet of paper some of the things that you like that the candidate has on their resume. Maybe John a couple of questions to clarify in between those factoids that apply to this person's resume. It's almost like a pre-rehearsal that Johnny Carson might have had for talkshow and it lets you know who this person is and that you let them know that you're thinking about them in advance of 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.

You're going to interview and you're going to have to work with this person for the next 20 years. If you're lucky. Think of it like driving a car or buying a car. They're going to go in and buy a new car and the dealership will only allow you to sit as a passenger in the car but won't let you test drive it. If you're the person who has to work with this person that your interviewing why let someone else do the driving?

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.

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.”





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.

Special Thank You: Kody Kahrizi for participating in this article.