Unity 3D Developer

You'd be surprised how often this question comes up, even if you aren't interviewing for a design position. Everyone wants a developer who has design sensibilities because it inevitably means she or he will be more involved and engaged in whatever is going on.

Knowing ahead of time how you might answer this question means you'll come off sounding like you've actually thought about a game in development terms. Game studios are looking for people who think as they play -- about what they're playing, how it's done, what could have been improved, and most importantly, what they can rip off.

One downside to adopting this mentality is that it becomes harder to enjoy a game for what it is, but that's an occupational hazard in all jobs.

Believe it or not, you can answer this question in an entirely positive way. However, if you decide instead to criticize a design or implementation decision in a game, be sure you have a solution to the problem too. It's not enough to moan about the final strider battle in Half-Life 2: Episode 2; you have to have an idea of how it could have been made more enjoyable, perhaps through easier car control, or not destroying all the supply stations so quickly.

If you decide to bash a game that the company where you're interviewing developed (and that takes courage; some companies will applaud you while others will diss you for not drinking the Kool-Aid), then ensure that what you're criticizing isn't something subjective but something that everyone has had a pop at. Be ready to back up the criticism with proof that it's an agreed-upon flaw, not just you being nit-picky.

At smaller studios, this is the 64 million dollar question. My advice is to be 100 percent honest. If you won't crunch, say so now. It may well put you out of the running for a job, but ultimately that's a good thing. No, really, it is! If the company works a lot of overtime and you don't want to do it, then taking the job is going to be punishing for everyone.

Having said that, the last thing any interviewer wants to hear is, "I won't do it" because that predicates a perceived lack of involvement and passion (not that passion should equal overtime, but the perception of refusing to do something before you're even in the circumstances could be the difference between getting a job offer and having the company pass you up).

Phrase your answer in such a way that you don't sound confrontational with the interviewer. She doesn't want to get into an argument; she just wants to know where you stand. Understand that this question is meant to gauge, roughly, how you might fit into the company culture.

As a programmer, do you work on home projects? As a designer, do you doodle design ideas or make puzzles? As an artist, do you do portrait work?

Having hired many people in the past, one of the things I can speak to with authority is that those people who spend their off time working on discipline-related projects are the ones who are always up on current trends, have new ideas, are most willing to try something new, and will be the ones taking stuff home to tinker with on their own time. Now that shouldn't be expected of everyone, but the sad reality is that there is competition for jobs out there, and those who are prepared to put in the extra work are the ones that are going to be in hot demand.

Demonstrating that you learned C# over a weekend because you thought it was cool for prototyping is exactly the kind of thing a programming manager wants to hear. Suddenly your toolset expanded, and not only did it show willingness to do something without being told, it makes you more valuable.

The only care to here is to not mention an outside situation that might detract from or compete with your day job.

Everyone has a pet project they would want to make if they had the chance -- it's just inherent in the game developer psyche. This is your chance to expound on it, and the more realized your idea is, the more it will be seen as proof that you know what you're doing.

Taking an existing idea and adding, "but I'd make it cooler!" isn't the answer (the number of times I've heard Q/A staff wanting to become developers tell me they want to remake Counter Strike "but better" is staggering); it just shows you have enthusiasm, but no original ideas.

Bonus points if you can take an existing IP license and make a compelling argument for a game out of it. People who can actually do that are at a premium in our industry since most tie-ins, well, suck.

This is a general question that applies to all interviews. There are two ways to answer: the big answer and the little answer.

The big answer requires you to have some knowledge of how the company operates. Who does what? Your goal is to slot your experience, passion and skills (and if you are a student, your passion, skills, and desired career direction) into any holes the company may have -- and it should have some. Otherwise, why are they hiring?

The little answer is to name some of your previous experiences and best qualities and hope that's enough.

Care needs to be taken that a) you don't sound arrogant in assuming the company will die without you and b) you don't say negative things about the company. Statements like, "Well, you obviously can't do good Q/A. You need a good Q/A manager," are likely to go down like a lead balloon. Frame your answer to suggest that you would bring extra expertise, and therefore improvement, to something that's already in place.

The most important thing here is to answer relatively quickly, and back it up. One of the fallouts of this question is age. Answering "Robotron!" to a 20-something interviewer might lead to a feeling of disconnect. But sometimes that can be good. It means you have to really explain why it's the best game of all time. Can you verbally and accurately describe a game to another person who has never played it? You'll rack up some communication points if you can.

What you shouldn't say is whatever the latest hot game is, or blatantly pick one that the company made (unless it's true and your enthusiasm is bubbling over). Be honest. Don't be too eccentric and niche, and be ready to defend your decision.

At smaller studios, this is the 64 million dollar question. My advice is to be 100 percent honest. If you won't crunch, say so now. It may well put you out of the running for a job, but ultimately that's a good thing. No, really, it is! If the company works a lot of overtime and you don't want to do it, then taking the job is going to be punishing for everyone.

Having said that, the last thing any interviewer wants to hear is, "I won't do it" because that predicates a perceived lack of involvement and passion (not that passion should equal overtime, but the perception of refusing to do something before you're even in the circumstances could be the difference between getting a job offer and having the company pass you up).

The most important thing here is to answer relatively quickly, and back it up. One of the fallouts of this question is age. Answering "Robotron!" to a 20-something interviewer might lead to a feeling of disconnect. But sometimes that can be good. It means you have to really explain why it's the best game of all time. Can you verbally and accurately describe a game to another person who has never played it? You'll rack up some communication points if you can.

What you shouldn't say is whatever the latest hot game is, or blatantly pick one that the company made (unless it's true and your enthusiasm is bubbling over). Be honest. Don't be too eccentric and niche, and be ready to defend your decision.

During rendering, each pixel is calculated whether it should be illuminated and receive lightning influence, and this is repeated for each light. After approximately eight repeated calculations for different lights in the scene, the overhead becomes significant.

For large scenes, the number of pixels rendered is usually bigger than the number of pixels in the screen itself.

Deferred Lighting makes the scene render all pixels without illumination (which is fast), and with extra information (at a cost of low overhead), it calculates the illumination step only for the pixels of the screen buffer (which is less than all pixels processed for each element). This technique allow much more light instances in the project.