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