Home What It's All About Who Is This Guy? The List Complete Archive Personal  RSS Feed People		Interview Questions By Kyle Wilson Friday, July 12, 2002 The Joel Test for rating the quality of a software team consists of the following questions: Do you use source control? Can you make a build in one step? Do you make daily builds? Do you have a bug database? Do you fix bugs before writing new code? Do you have an up-to-date schedule? Do you have a spec? Do programmers have quiet working conditions? Do you use the best tools money can buy? Do you have testers? Do new candidates write code during their interview? Do you do hallway usability testing? This is an article on interview questions, but it isn't what you think.  You see, there are lots of articles out there on how to interview job applicants, test their strengths, and see if they mesh with your team.  And there are lots of articles out there on how to answer those questions if you are a job applicant, so that you get the job. This isn't an article like those. I assume that if you're reading this, you're a capable game developer, a good software engineer, and a valuable asset to any team that's lucky enough to have you.  Really.  When you go into a job interview, the important thing for you to remember isn't the answer you worked out for when you get asked, "What is your greatest weakness?"  The important thing for you to remember is the questions you need to ask, if you're going to figure out if this job is right for you. A job interview is your best chance to find out information about the place where you could be spending most of your waking hours for the next few years.  So as you talk to your interviewers, here are some questions you might want to ask them: "Where does your money come from?  How much do you have?"  A friend of mine quit his job to work for a game company.  Three months later, he got laid off with forty other people.  It's a good idea to find out as much as you can about how secure a potential employer is so that you can evaluate the risks before signing on. "Are you the only game company in town?"  Clearly there's a great deal of turnover in the game industry.  We're in a continual state of churn.  Think about where you might go if the company you go to work for fails. "Do you require a non-compete agreement?"  Non-compete agreements aren't likely to stand up in court, but it's better not to take chances.  Being sued, even unsuccessfully, can't be any fun.  And non-compete agreements reflect badly on the companies that require them.  Why do they feel they have to coerce employees into staying? "Where do you see the company going in the future?"  You need to decide whether you think your potential employer has a viable business plan.  If they just want to make free online games in the hope of selling web advertising, you probably don't want to work there. "Tell me about your company structure."  Learn the lay of the land.  Who would you be reporting to?  Who do they report to?  Who would you be working with?  How senior would you be? "How do you score on The Joel Test?"  This one covers many of the basic software engineering questions.  Most of the game companies I've worked at score pretty low on the test.  Everybody used source control -- though I hear horror stories suggesting that even this isn't the case everywhere -- but there are still places that just don't believe in daily builds and don't think they can afford testers.  And nobody writes design specs, though they should. "Do you have an in-office PA system?"  This is really part of Joel's question 8, but it's a personal pet peeve of mine.  Any company that develops software should know that you do not distract the developers by paging executives on everybody's phone. "What games have you made?"  It's good to work for a company that has a track record of making AAA titles.  It suggests that they may make AAA titles again in the future. "What games are you working on now?  What do you have planned?"  These are the projects that you might be working on.  No matter how successful a game may be, you'll enjoy working on it more if it's something that you enjoy. "How well do you pay?"  No computer scientist goes into the game industry for the money.  But it would be disingenuous to say that salary is irrelevant.  Salary is just one factor among many, and you should balance it against working conditions, your interest in the product you'll be developing, and other benefits. "Do you pay for relocation?"  If appropriate. "How many hours a week do you work, on average?"  Every project will have some crunch time toward the end, but if developers have to consistently work more than forty hours a week, it's a sign of something wrong with the company. "Describe your data pipeline."  If the overall development process is healthy, then artists and designers will be able to easily create new game content and add it to the game. "Can I see your tools?"  Most of the work that goes into designing a game isn't the high-concept stuff.  Most of the work is ongoing tweaking to make sure that the player is never bored, that play stays balanced, and that the game stays fun.  It's almost impossible to make a decent game of any size without good tools. "Would I get to go to GDC/SIGGRAPH/AAAI?"  Different people find different rewards in software development.  If you're like me, one of the greatest rewards is the ongoing opportunity for learning and growth.  Good employers will encourage and facilitate that. "Do you have a tightly knit development team?"  Nothing helps productivity more than having a well-meshed team.  Nothing makes a job less fun than working in a group split by infighting and buck passing.  Pay attention.  Do you interview with the whole team you'll be working with?  After all, they'll be living with you, they should all get a say.  Are team members easily accessible to one another?  Do they seem to get along?  Does the company have teamicidal practices like incentive pay or an employee of the month program? "Tell me about your software development process."  The answer isn't really important.  It's just important that there is an answer.  If a company doesn't have a process, they're just playing Three Card Monte with their publisher, only even they don't know which card's the ace. "Tell me about your game engine."  This is code you'll be working with for years.  You should try to learn something about whether it's well designed for growth. So that's it.  Remember, no company is perfect.  Any game company, like any game engine, is going to involve tradeoffs.  And many of the more important attributes of a great company are harder to pin down.  Are the employees enthusiastic?  Do they love the game they're making?  Is there a common vision that everyone understands? A company's answers to the questions above may be less important than what they want their answers to be.  If their goals and yours agree, then you can be an agent for change and bring them closer to their -- and your -- ideal.  If your goals are different from the company's, then you're more likely to annoy your co-workers and make yourself miserable fighting the system. But those are my questions.  The answers ought to spur more questions for you to ask.  I hope that the process will help you get a better sense of the alternatives available to you and the tradeoffs between them as you consider potential employers.  And as an added benefit, wherever you end up, you'll have learned something about development practices at a number of game companies.  That can't be a bad thing.   I'm Kyle Wilson.  I've worked in the game industry since I got out of grad school in 1997.  Any opinions expressed herein are in no way representative of those of my employers.
Home