So, You’ve Decided to Interview For Game QA


Yep, QA is the way to becoming either a developer (coder) or associate producer (slave for real producers). Artists, writers, other folks, you can go this route too, though I am not sure if it will help as much as a degree from an accredited school. Generally, getting a Quality Assurance job is fairly easy if you’re asking at the right time, for the right company. Smaller developers are more difficult to get into since they have fewer positions and fire people less often, less turnover. Publishers and places like Microsoft are incredibly easy to get into, however the larger the company the worse they will treat you. Developers are generally nicer to their QA staff.

I should explain that console manufacturers certify games (certification testing) before they allow them to be released. So what this means is not that the game is any fun at all – believe me, many games you will test are horrible, wretched titles that need to go back to the swamp in new jersey from which they arose – just that the game starts at the title screen when you press the start button. There are a number of other requirements for certification, these make up the Technical Certification Requirements (TCR/TRC, both are the same). Separately, the game is also certified for assurance that the game is functional, which is known as (can you guess?) functionality testing. Functionality testing often pays less, and is more demanding. Though you’re more likely to play the game with functionality testing than you are with certification testing.

So, you’ll see certification testing at console manufacturers, like Microsoft, Sony, and Nintendo. However, studios/developers that make games often also check the game before it gets to the console manufacturer. It costs developers/publishers money to send the games through certification testing at the console manufacturers, so the developer and publisher will test it beforehand.

This is all relative of course, I am treated very well at my current QA position. Mostly due to the fact that I have managed to get work with a smaller developer. Besides being the most charming Quality Assurance Engineer on the planet, there are other good skills for interviewing for this kind of position too. Ahem, ordered paragraph list, please!

  1. Know some games you like, beyond just “Metal Gear Solid is awesome!”. Talk about how you think that perhaps Hideo Kojima should have gone a little bit easier on the story arc and made it less confusing. Or about how Halo 2 has obvious Level of Detail errors during the cutscenes. People you talk to at your prospective employer will want to hear about your real interest in games, if they don’t hear it, they will think you’re just there because you think the job is easy (regardless of you saying exactly the opposite). You must sound interested and well-prepared.
  2. Along with the LoD errors in Halo 2, mention other things you’ve noticed in games that seem to be broken, like the time you fell through the world in Grand Theft Auto 3. Or how Doom 3 had a monster closet where the AI failed and the monster stood there taking fire until he died without responding. Stuff like this is real good fodder for talking during the interview.
  3. You may get asked ridiculous questions. How do you test a stapler? How do you test a chair? Et cetera. This is (in my opinion) totally useless for actually finding out if you can test anything. People think that questions like this mean they’re smarter for asking them because they read about it in some fancy interviewing book. These people are morons (in my opinion). This may be useful for finding out how well you deal under the pressure of being asked a bogus question while working under pressure.
  4. Don’t dress well unless you’re interviewing for a testing position on an IBM game. Jeans and a slightly fancy shirt are OK. A suit is too much. Obviously everything should be clean and have no visible stains/cat hair/stink like pot. Please also shower before the interview and put on deodorant.
  5. Know what you’re getting into. QA is not easy. The lowest paying and first jobs with QA are the ones where you only test for functional crashes, this is where you will sit in a cave with 60 other sweaty testers playing Barney’s Cookie Eating Adventure for 8 hours a day until the game won’t crash anymore after it has been rejected and sent back to testing 40 times. You may get stuck with this kind of testing no matter what you do if all the other positions are fully staffed.
  6. Arrive early, bring a Nintendo DS or something to play whilst you wait, especially if you get nervous around interviews. It’ll also give you something to talk about with anyone who walks by and inquires about what game you’re playing.
  7. It’ll help if you’ve done some work outside of testing, especially anything else game related. I write (terrible) reviews for various games on web sites, and maintain various open-source game projects. These are also good talking fodder, and especially good for filling your resume before you have a lot of testing experience.
  8. Take any water that is offered to you. Don’t drink red bull or something else that will make you edgy.
  9. Have fun with your interviewers, if you can crack some jokes, do it as long as your audience is receptive.
  10. You may be asked to demonstrate your testing skills in some way. I can tell you that I’ve been shown prerecorded game play of obviously unfinished games and been asked to report errors I’ve seen. Don’t worry, the errors in these are obvious. Real testing generally doesn’t have such obvious errors, especially if you are going for a publisher/TRC, TCR approval position. Developers usually iron out really big stupid errors before they get to that point unless they are under extreme pressure from their publishers to get things to certification. I’ve also been given an actual in-test game and asked to test it, this is actually easier than the video tape version in general.

7 Comments

  • Anonymous wrote:

    In regards to water and Red Bull:

    QA job or otherwise, I’ve been told to always accept, with thanks, whatever drink is offered to you during an interview, even if you don’t want it, since it’s generally perceived as cold or unfriendly to refuse it. If they generally ask you if you want something to drink, ask for water to keep it simple.

    You don’t have to actually drink it, just carry it around with you. This also has the benefit of being there if you suddenly find you need it, without having to ask, and preventing people from offering you more Red Bull if you’ve already got a can in your hand.

    Don’t know if that’s actually good advice, but a recruiter on a development job told me that before shoving me into an interview, so take it for what it’s worth.

    Also, mind your bladder and your personal reaction to caffeine.

    These are the stupid little details that make a massive difference in any job interview, if you can believe that.

    Good post, Zachary.

  • Zachary wrote:

    Thanks,
    Yeah redbull if there is nothing else. I hate to encourage the drink since it is the drink of total submission to our corporate masters (So that we might work more hours). It is good advice to drink whatever is offered though, yeah. Also gives you something to do with your hands.

  • Michael Russell wrote:

    I want to call out one minor issue with this list…the “test a stapler/etc.” post.

    When asked that question, you aren’t being asked because the person on the other side of the desk wants to seem smarter than you.

    It’s a nice, abstract way of figuring out your thought process when approaching a problem, and how you approach the task with little instruction gives us an idea of how you are going to approach testing.

    Are you going to request additional information? Are you going to just test functionality? Are you going to test it to failure? Are you going to look for corner cases? How much are you going to rely on your experience with it?

    It may seem like a really stupid question, but the stupid questions can often reveal a lot about someone’s thought processes. Especially in QA, how you think is as important as how thorough you are.

  • Zachary wrote:

    I think it is useless because not only isn’t a stapler a game, I haven’t used a stapler in years. I got the question right (there was literally a list of 20 or so things you were supposed to point out to test), however I still think it is nearly totally useless. Something better might be a controller (game or remote!).

  • Sam Kalman wrote:

    I also find value in the sort of questions that require you to think outside the box. Just because a stapler isn’t a game doesn’t mean it can’t be tested. Stapler manufacturers have a QA process too. Evaluating defects in a game is a lot more complex and difficult than evaluating defects in a stapler. If I can’t trust a tester to recognize a malfunctioning stapler, I’ll have no confidence that they’ll be able to tell when a game element isn’t working properly.

    That said, I think handing an object to an interviewer and asking them “How would you test this?” is a lot more effective, because I like to talk about testing something tangible.

  • Zachary wrote:

    I also think it wouldn’t be so bad if it weren’t over the telephone. I guess it seems goofy that I hardly ever use a stapler, but I can’t be the only one.

  • Excellent posting with great information. I also agree that accepting the offered item (beverage, haggis on a stick, whatever) is the polite thing to do. You don’t have to ingest it, just accept it. The ‘testing a stapler’ question isn’t so bad, as it will give some insight into your thinking. If they have a ‘non-confidential’ variant of the game available, that would always work best. Especially if they ‘think’ it is bug free, and you find something!

Leave a Reply

Your email is never shared.Required fields are marked *