Wednesday, January 23, 2008

The Interview Game

Last year, I had several occasions where a student would come up to me, nearly freaking out: "OMG, I have an interview with a game company! What do I do to not screw this up?" (Yes, they actually pronounce "oh-em-gee" when they're sufficiently panicked.)

What follows, then, is my own advice and observations on the interview process. It should be primarily of interest to students, or to educators who get these kinds of questions from their students (especially educators who have not been through a game industry interview before). It may also be of some use to industry people looking to conduct an interview; usually, you don't get any training in how to interview a candidate, so maybe you'll get some ideas about how to make the most of your time.

First, let's get some common questions out of the way.

What do I wear to the interview? Dress policy varies from company to company. Most are casual, but that doesn't mean that ripped jeans and a t-shirt is appropriate everywhere. Best thing to do is ask, when the company calls you up to offer you the interview in the first place: "By the way, I know this is different at each company. How do you prefer candidates to dress for interviews?" If you miss your chance then, you shouldn't lose any points for calling back ahead of time; if you have an interview, you've already been given the phone number of HR, if nothing else. If you left this until the last minute and you have to make a snap judgment, business casual is a decent bet... or, go for a business suit on the theory that you can't be overdressed.

Personally, I've always worn a suit to the interview, with the understanding that I'll never be seen wearing it again. In one interview, someone who shall go unnamed hired me, but told me that if I was ever seen wearing a suit again I'd be fired.

What do I bring to the interview? First, bring anything you're asked to. If you're hiring for a programmer position and they tell you to bring some code samples to your interview, by all means do what you're told. That's the easy part.

Bring a copy of everything you've sent to them, including resume, cover letter and any other samples or portfolio materials. If the person sitting across from you starts reading directly from your resume and asks you questions line-by-line, you can follow along.

Bring a notebook and something to write with. This avoids the embarassment of having to ask for a pen if you're asked to sign something, and you should be taking notes as you go (see below) -- you can bet they'll be taking notes on you.

What questions will I be asked, and how do I answer them? Ah, this is the heart of the matter, and the reason why I call this an interview "game." Because it is a game. For the company, the goal is to find the best candidate. For you, the goal is to get a job offer, and to figure out if this is an offer you'd accept. It's a turn-based game, where the interviewer asks a question and then you answer it. Here's the secret, though: the game is stacked in favor of the interviewee!

Here's why. For every question asked, the interviewer is giving away information about the company: its values, its culture and the kinds of things it's looking for in a candidate. And they speak first, so you always have the information advantage. You win the game by deducing, in realtime, what each question really means. Then you give an answer that also works to your advantage, and you're ahead with each question and each answer.

Here's some examples of interview questions and what they really mean. You'll notice that I don't give any answers here. That's because there is no "right" answer; each answer you give is an expression of who you are. If I gave you answers, you'd be expressing who I am, but I'm not the one in that interview room. Also keep in mind that these are just examples. The trick here isn't to memorize these questions, it's to get used to the process of understanding what a question really means so that you're giving the interviewer the information they're looking for! As you can see, most questions are not 100% straightforward:

Question: How do you feel about working overtime?
Meaning: You will be working overtime. Lots and lots of overtime. Do you think you'll enjoy this job so much that you won't mind when it takes control of your entire life?
What they really want to know: Are you passionate about this line of work, or are you looking for some cushy 40-hour-a-week desk job?

Question: What's your biggest weakness? (Variant: If I hire you, what will be my greatest regret after six months of working with you?)
Meaning: We know that no one's perfect, and that's okay. We just want to know that you're willing to become aware of your own imperfections, and that you can improve them or work around them.
What they really want to know: Are you capable of reflecting on your past experiences and finding your own faults? Also, can you take criticism well (you probably can if you spend time criticizing yourself)?
Worst possible answers: "My biggest weakness is that I'm totally incompetent and will single-handedly run your company into the ground." (Honest, perhaps, but doesn't tell them what they want to know.) "My biggest weakness is that I work too hard." (Total BS and we know it, and implies that you're unwilling to give yourself serious critique.)

There are technical questions that vary by field, that also sound very strange unless you realize what it is they're really looking for. Some examples:

Design question: Pretend you're an architect. Design me a house.
Meaning: How do you approach a totally open-ended project?
Worst possible answers: Jump in and start drawing floorplans (you're willing to design a game without doing any research ahead of time). Complain that you're not an architect and it's an unfair question (you're unwilling to learn something new, or stray outside your comfort zone, and you don't understand enough of game design to see the parallels with architecture).

QA question: Explain how to use a telephone. (Variant: explain to a space alien who's never seen one.)
Meaning: How do you describe the steps to reproduce a simple bug to someone who's never seen it?
Worst possible answers: Complain that everyone already knows how to use one, so the question is pointless (you don't understand enough about QA to see the parallel between explaining something obvious and explaining "obvious" repro steps for a bug). Be condescending or patronizing in your explanation (implies you'll treat programmers the same way if they can't follow your written repro steps).

Programming question: Explain the concept of class inheritance in terms that my technophobic grandmother could understand.

Meaning: Communication skills are important for programmers, particularly being able to explain technical ideas to nontechnical people (such as designers, artists and producers).
Worst possible answers: Give an explanation right out of your Computer Science textbook (you only know how to communicate with other programmers). Say that you don't know what class inheritance is (you were sleeping through your core curriculum). Say that it's impossible to explain such a technical thing to someone who has no programming experience, so it's an unfair question (not only can't you communicate with nontechnical people, but you're not even going to try).

Thursday, January 17, 2008

Two-Year and Four-Year Students

Having now worked in both a four-year university and a two-year community college, my first impressions of the students are not what the stereotypes would suggest.

The community college, ironically, has less of a sense of community. Most students taking my classes are taking them alone, not with a large group of friends. I think this is partly because of the lack of dorms and other 24/7 student activity on campus, and partly because a large percentage of students are only taking classes part-time.

The community college is far more diverse. Between my two classes I have people from five or six different countries, with an age range that varies from "working professionals with 20 years experience" down to "high-school students taking advanced classes that their school doesn't offer". In a four-year school you're seeing mostly college-age students, with a disproportionate number of locals (or at least, that's what I've seen). I must say, I've grown used to being the oldest person in my classes, and it feels strange when that's not the case anymore.

Community college students seem, generally, to be more prepared before taking a class. More than half of my game industry students knew who Shigeru Miyamoto is (one even recognized Gunpei Yokoi's name), and most had heard common industry terms like AAA and ROI and LOD. In my four-year classrooms, it's usually more in the 10-20% range. If I had to guess, I'd say this is because community college students tend to be older (and therefore more experienced) and also more self-directed. Not every student is a superstar, but there seem to be a greater proportion that are above the curve. (If you were in my classes last year and you're reading this, I'm obviously not talking about you as being anything other than spectacular, of course.)

Most of my community college students are not planning on just getting a two-year degree and stopping. The majority either already have a Bachelor's (or higher) and are branching out into a new field, or they're just getting their general education credits out of the way (where the tuition is cheap) and then they'll transfer to a four-year institution.

I was expecting to have to deal with a lower caliber of student at a community college, but I've been pleasantly surprised.

Saturday, January 12, 2008

Culture Shock: Parking Policies

It didn't occur to me until recently that different institutions have wildly different ways to treat faculty when it comes to parking lots, of all things.

In my experience, parking for a normal job is pretty uneventful. Some buildings have private lots and you get a sticker or an assigned space or something, while smaller companies might need you to park on the street nearby. Either way, the company is paying you to come to work, so it's in their best interests to make it easy for you to actually arrive. Also, most companies aren't so huge and bureaucratic that Parking Enforcement is its own private department... especially in game development.

For colleges and universities, by contrast, parking is a huge problem. When you've got thousands of people commuting every day, you need some way to ensure that parking spaces are allotted fairly. Unfortunately, the parking office is usually not part of Human Resources, which means that a lot of places inadvertently send some pretty harsh messages. Here's three policies at three different institutions that I've observed (feel free to add your own in the comments):
  • Separate parking lots. If you're a student and pay a fee, you get a sticker for the student lots. If you're faculty, you get to park in the faculty lots for free, but you're not allowed in the student ones. There are also some "seniority lots" at prime locations on campus; when someone with a space dies or retires, whoever's most senior on faculty gets the space. What this says: Students and faculty are different people, so we're putting up artificial walls to make sure they don't accidentally get to know each other. Also, no matter how great a teacher or researcher you are, what really matters is that you stay here for a long time.
  • Separate parking spaces within many lots. Each lot has some student and some faculty spaces, and if you pay a fee you get a sticker that gets you in to the right kinds of spaces in each lot. You have to pay even if you're faculty. What this says: This institution doesn't care who you are. You are nothing to us, a mere insect. If you don't like it here, there's a line of people out the door waiting to replace you, so put up and shut up.
  • Common lots. There are a variety of parking lots and every space is exactly the same. Students pay for a parking pass, faculty get one for free, but everyone is fighting for the same spaces (and they're a bit scarce at certain times during the day). I haven't had a space stolen in front of me by one of my own students before, but I'm sure it happens occasionally. What this says: We're all in this together... or, every man for himself... depending on how you look at it.

Tuesday, January 08, 2008

Slowing Down

In my Analysis class today, I was asked to speak a little more slowly than I normally do.

To my surprise, consciously slowing down my speaking made the entire experience an order of magnitude better. My brain had spare cycles to actually consider what I was saying and how I was saying it. I never spoke so fast as to get ahead of my own thoughts (which then ends in a characteristic uncomfortable pause). My speaking was clear, and the students were all paying close attention. I think it made me easier to understand. It was also a lot easier on my vocal chords. And it made it easier for students to ask questions or add to the discussion because there were more pauses. I was afraid that speaking too slowly would make me sound stupid, but really it just made me sound confident.

I'll probably continue to speak slower in every class from now on, not just this one.

What really surprised me was that I never really thought before about how fast I speak. When I get excited about a topic (which is pretty much always, if I'm talking about game development) I talk faster; this is true of most people I know. And when I'm talking with other developers, we can get away with this because we're already familiar with all the basic concepts and we've done this for so long, that our minds work as fast as our mouths. With students who are just getting past the concept of "oh, you mean I can't just come up with an idea for a game and sell it?"... well, maybe not so much.

So, I may have accidentally stumbled onto a little secret that makes it easier to teach. I bet this also works well for presentations. I also bet it's something that's obvious to anyone who's been doing this for any length of time.

Friday, January 04, 2008

System Analysis

What do game designers do? They make the blueprints, termed design documents, that describe the nature of the software that the rest of the team will build. Writing and maintaining this documentation is itself a full-time job in most large projects. It's necessary; a game without a designer is likely to be difficult to use and not much fun.

These same tasks are useful for any large software project, not just games. So where are all the "game designers" in the greater software industry?

These people do exist, but it's hard to find them. Not all companies have them; some companies still operate under the antiquated assumption that anyone who can program in Java is fully qualified to design the software architecture. The companies that do have "designers" call them many different names. Microsoft calls them program managers. Other places call them system analysts. Some companies with highly technical systems require their "designers" to write some code, so they call them programmer/analysts. Still other places hire from outside, and they're simply called consultants. For my purposes, I think system analyst is the most descriptive, so I'll conveniently go with that term.

And so it comes to pass that I find myself teaching a course called Systems Analysis. While it has nothing overtly to do with the game industry, the topics overlap with game design a great deal. We talk about the iterative method of development, rapid prototyping, user interfaces, focus groups and research into the subject area of the software. It's the same thing, except with all the fun apparently sucked out of it.

And this, ironically, is why I'm so excited about teaching the class. It lets me put into practice everything that I've been preaching about using game-like techniques to teach a non-game class, and the evils of multiple choice. If I can take this class and make it fun, it validates everything I've been doing as a game-designer-turned-teacher. And if not... well, I can always go back to my game classes with their inherently fun content.