#game programming interviews

Were I you, I'd do two things.

First, I'd take a sample of some code I've written for a project and post it to a programmer-specific website like Stack Overflow, asking for critiques and readability. As a programmer, your number one responsibility is to write functional code. Your number two responsibility is to write portable, legible code - if you want to get hired somewhere, you're going to be working on a team, and that means that other engineers are going to have to be able to look at your code and understand what it's doing. Imagine taking over a game system from somebody... say a camera system, or an animation system. The last thing you want is to spend hours trying to puzzle out what exactly the other person was doing. This is why legibility is usually more important than squeezing out that last bit of performance. If you're the only one who can understand it by looking at it, the code loses a lot of value if you ever leave or are unavailable. 

The second thing I would do is either visit the book store, or look online for programming tests and programming job interview questions. There are a lot of varying opinions on the necessity or usefulness of a programming test, but the only programming positions I've ever gotten that *didn't* require a programming test were ones where the job was already basically guaranteed to me because I had worked there before and they wanted me to return. You should be able to adequately complete both written tests and the verbal interview-type questions. One of the books I suggest is Programming Interviews Exposed. It's a decent primer on what interviewers will ask about basic programming concepts, and I've seen quite a few interview questions like the ones in the book. I've also personally used programmerinterview.com as a supplementary site, though the overall content isn't as good as the book I mentioned. Finally, if you are aiming for a gameplay position in specific (which is my expertise), you should understand and be able to explain what vectors, dot products, and cross products are, and why they are useful.

I found myself in a short interview today, and I was reminded of something that I've seen quite a bit. I thought I would share for the prospective developers out there. This is in regard to a programming role in specific, but it does apply to other roles as well.

If you want a job as a game programmer, it will take a lot more than just reading a book or taking a class. The inevitable question that almost always gets asked at a job interview is "On a scale of 1 to 10, how would you rate yourself at <insert language here, usually C++ for game devs>?"

The most common answer from almost every candidate out there will be "a seven or an eight", even if these kids are fresh out of school. It seems like a "safe" answer - it seems like it would show strength, but a little humility. Let me tell you, the concept of what a seven or eight really is will vary from person to person, but the important thing to realize is that you're going to be interviewed by people who have been programming for years. They've got a lot of experience, and they'll know if you try to BS them because they've seen (and fixed) the sort of code you'll probably be writing. 

Some of the programmers I know actually like to see how far the prospective entry-level programmer has gotten in the "teach yourself C++ in 21 days" type books they get. And by giving an answer of 7 or 8, you're basically saying you know most of the ins and outs of the language... and that's really something that most of the books won't cover, especially the "teach yourself" type books. C++ is actually not a single language, but it's a federation of languages mashed together. That means that to know everything there is about C++, you need to know:

C as a functional language

Object-Oriented C++

Templates and Dynamic Programming

the Standard Template Library (STL)

Do you know how much those teach-yourself books cover? If you say "a little of the first, a little of the second, and a little of the fourth", you'd usually be right. If they asked you how the particulars work and why they behave that way, would you be able to answer? Are these things you would expect someone who claims to be a 7 or an 8 (out of 10!) at C++ to know?

I'll be honest here - it's entirely fair for you to give a much more honest appraisal of your own skills. And that honesty will be much more likely to impress the interviewer if you say so, because oftentimes the first step to mastery is recognizing what it is you don't know, so that you know what you can learn. If you know that you don't know something, it means you can learn it. If you don't even know that you've got holes in your knowledge, then it's that much harder to teach you. This actually applies to most fields.

Senior devs aren't necessarily looking for mastery if they're hiring for a junior position. They know what they're looking for - someone with some base skills and the potential for improvement. They know that their ideal candidate won't be a superstar, but someone who they can teach, mentor, and mold into a stronger and more useful member of a team. What they want is someone with the potential to be great, and they're willing to take a chance and hone someone with that potential to bring it out. So think of it from their perspective. If you were trying to pick a candidate to take on, what sort of candidate would you want?