Talking the Talk, Walking the Walk

So you've gotten the call, and they've scheduled an interview. So far, you're ahead of the odds. But needless to say, not everyone who interviews gets hired. It's the second phase of the screening process. (Some places have a third phase, an introductory training session. More on that later.)

All the standard tips for job interviews apply here. Dress professionally, bring a copy of your resume in case they ask to see it, get there half an hour early, greet the interviewer (or interviewers) with a firm handshake, maintain eye contact, show confidence and courtesy, don't bad-mouth any previous workplaces, and when prompted, ask questions about the position. Simple questions, like whether there's a dress code or what the schedule is, can be asked casually. If you ask anything a bit more prying, like what the job pays or what the benefits are, phrase it as if you're asking for a favor, as in, "Can I ask what the job pays?"

That covers the "personality" side of the interview. Needless to say, a good personality certainly helps; if you can charm the interviewer(s), and show them that you'd fit in well as a teammate, you're that much better off than someone who seems nervous or awkward. But it's not enough in itself to get you a testing job, at least not usually.

You also need to know at least the basics of what a tester does, and how they do it. And that's what I'm here to tell you about.

Anyone who's been a gamer for any length of time has encountered bugs before. Think back to some of the bugs you've come across.

Unless you already find bugs for a living, it's likely that most of the ones you remember are the big and obvious ones; we all remember that time the game froze in the middle of the final boss fight, or that stupid exploit that ruined multiplayer until they finally patched it, or — worst of all — that time our save data got corrupted.

But also consider the little ones, the ones most gamers just ignore. Think about that typo in the dialogue from that last RPG, or the time the subtitles showed up at the wrong moment, or the enemy who spawned halfway into a wall and got stuck. Think back to that time you were able to loot a chest twice by clicking it again at the right time, or the NPC advice that doesn't make sense in context. Remember back when that character nodded his head and put his chin through his chest, or the way your new piece of armor kept poking through your old one, or that time the game forgot to draw the background until the cutscene was halfway done?

There's an incredible number of ways a game can go wrong. How many ways can you think of?

Now: How can you make the game go wrong?

An ordinary gamer hates finding bugs. They almost always get in the way. They certainly break immersion, take you out of the experience, remind you you're sitting there holding a controller, watching a TV screen.

A tester wants to find bugs. That might sound obvious, but think about what it means. You're not just playing the game, as a regular player (the "end user") might, until you happen across a glitch; you're going out of your way to cause those glitches. You're stressing the game until you flush those bugs out of hiding, and it's not enough to just make them happen; your job is to figure out how to make them happen consistently.

There'll be a post later on ways to find bugs, but the main guideline is simple: Do the unexpected. Do what the game's developers didn't expect you to do, and didn't plan for. In any game, the "critical path" — the path the end user is most likely to follow — gets the most attention from the development team. So find out where they paid less attention, and poke around there until you find something.

Practice at home before the interview. Or before you apply in the first place. Pick a game. Preferably one you know is buggy, but just about any game will do. Find a bug — it can be a big bug, or a little one — and then find a consistent reproduction process (a "repro") for it. Write the repro down, with instructions clear enough that someone else, someone who hasn't necessarily played the game before, can sit down, read your instructions, and make the bug happen again.

Soon, we'll go into more detail on writing a bug, and we'll talk about what separates a well-written bug from a poor one. But for now, just get a feel for what kind of bugs are out there, and what sorts of ways there are to find them. Then, when the subject of the interview turns to the testing process, you can impress the interviewer(s) by describing the kind of bugs you've already seen.

(Just a note on that last point: When talking about bugs you've seen, avoid discussing well-known bugs, particularly multiplayer exploits. We all know about the Javelin glitch; it's all over the Internet already, and telling them you've seen it won't get you any points. Pick lesser-known bugs, bugs you've found personally, if you want to impress.)

Other tips to be aware of for game-specific jobs:

- They want people who (A) love games, and (B) can pick them apart like a master surgeon. The more you show them both, the better off you are.

- Know the company. Know their games, and their history. Of their games, which one's your favorite? If you haven't played any of them, it might be time to rent, buy, or borrow a few.

- Remember, you may well be up against a dozen other candidates, some of them more experienced than you. What is it about you that makes you the best choice? Come up with an answer. Make sure you convey it to them. And if you can't think of one, build one up before you apply. Don't just BS; it's got to be something you know is true. If you're talented, and you're confident in your talents, show that confidence. If you're not as sure of your talents, build up what you can do. Show them a great work ethic. Learn everything there is to know about their last ten games, and find any bugs that those games shipped with. Have you led an interesting life? Find a way to work one of your best stories into the conversation, and hint at a promise of more.

And "conversation" is a key word here. Don't think of it as an interrogation; think of it as a chance for the interviewers to get to know you, and for you to get to know them. Be professional, of course, but also friendly.

When the interview's over, if you're lucky, they'll hire you right then and there. Conversely, a "We'll call you" doesn't necessarily mean no; it can mean, "We like you, but we have five more interviews scheduled for this one position, so we'll pick the best candidate once we finish with all of them." Feel free to follow up after the first week, and don't assume it's a no until you go at least a couple of weeks without a response.

If it is a no, that doesn't necessarily reflect badly on you; it could just mean that someone more qualified, or luckier, happened to apply when you did. But either way, think up any ways you can better your chances for next time, pick a different place, and apply there. If you hit it off well with an interviewer, that's good whether you're hired or not; you've started building industry contacts.

If you get a yes, then congratulations! You've already gotten farther than a lot of other people. But get ready — whether they put you through a formal training program or have you learn on the job, you're going to have to be a quick study. You'll have to learn what kind of bugs there are, how to find them, and how to report them.

Next time, we'll start covering all that in detail.