Getting a games programming job - Tip 10 - More interview question topics

When I recently posted about finding programming interview questions online, I neglected to mention a couple of other areas that games companies like to ask about.

• 3D Math is popular. Here's a bit of a sample of it I found on a quick search.
• 3D Rendering. There's a long article here which takes you through most of the important concepts.
• General Math is pretty important. I'll not give a link to it, it's a bit too big.

One more note is that there are quite a few sites which list interview questions which Microsoft has asked in the past. A quick search will show up sites of questions like this.

Getting a games programming job - Summary

One of my main topics has been giving tips on getting a job in console game programming. Here's a summary of all the posts on the subject:

• If you want to work on console games, focus on learning C/C++.
• Spend your free time working on simple demos.
• It's good to know STL, but don't rely on it.
• Creating a website is a great way to show off your demos.
• Know what to expect of the interview process.
• Some tips on sending your application.
• Practice answering some interview questions. Also a second post on this.
  
• Know what to do after the interview.
• Don't take the 'easy route' in group projects.

Books on games

I just came across the following article. It's a pick of '50 books for everyone in the games industry'. There look to be some interesting books in there.

How much does it cost to make a game?

There’s quite a range of games being made. A simple flash game might take under one man month to develop all the art and code, whereas a high-end console game could take in excess of 2000 man months across all departments (e.g. 100 people for 20 months). If a game can generate a profit that covers the cost of development, marketing and publishing, then it is in one sense, a success.

I’m not very familiar with the money end of game production, but lets make up some quite inaccurate numbers for fun. Lets say that the average worker costs $60,000 per year. We’re working on a 1000 man month project. This means that the salaries for the team add up to $5 million. Then we add a marketing budget of another million. And lets throw another million on for things like publishing, middleware and recording of music and voices. So in total this makes $7 million. I think this number is in the right ballpark, but many games will have a far higher budget, and the trend towards more and more impressive games keeps on pushing it up higher.

If the game is selling in the high street for $40, let’s say that half of that money makes its way back to the publisher (I’ll treat the publisher and developer as one entity for simplicity). That means we need to sell 350,000 copies before we start to make a profit.

I don’t have a particular point or statement to make, I just like throwing numbers around and explaining roughly how things work. You can see from the above that developing large scale games is a risky business. There’s potential for a lot of money to be made if you have a hit, but it’s expensive to build the game in the first place, and if you fall short of the numbers then you can fail to make back your millions.

Working on small-scale games on the other hand gives less risk, and generally speaking, less potential rewards. This said there’s a lot of interest in casual games these days and money being made.

One thing I like is that there’s quite a large spectrum of games being made – cell phone games, hand held consoles, next generation console games, Xbox360 Arcade games, serious games and casual games. It means lots of different niches for different groups of companies, rather than everyone just trying to make high-end console games.

Note: This post contains a lot of made up numbers. They’re just rough guesses built up from working at a few different companies.

Getting a games programming job - Tip 9 - Working on group projects

I interview quite a few people who’ve worked on group projects at university. In an average group project, I’ll often see that two people did almost all the programming work, one person did a trivial bit, and then one person performed some other role like writing the fluffy game design doc (which is far beyond what gets implemented:) and doing graphics.

If this was isolated, it wouldn’t be too bad, but what normally happens is that on the next project, people perform the same roles. The coders code, and the people who worked on other things last time, again work on things other than code. By the time university is over, the code dodgers may well have the same GPA as the coders, but when it comes to interviewing for a coding job, they can have a hard time.

Recommendations:

• Don’t let it happen to you. When there’s code to be written, jump in, and do as much as you can.
• Don’t let it happen to your friends. Help to structure your team so that everyone codes. This is both ‘being nice’, but also building up skills you’ll need in working in a team of programmers.
• If you somehow get stuck in a non-programming role, then do more coding on your own outside of your class projects. Writing demos and games on your own can be one of the most important things you do in terms of getting a job.

The more coding practice you get, the easier job interviews for programming positions are.