Thursday, September 28, 2006

Getting a games programming job - Tip 8 - Post Interview Feedback

After the interview, what’s next?

The Slow
Hopefully the company will follow up with you pretty soon after the interview. Sometimes though, either through them being busy, losing track of you, or waiting to see how other candidates turn out, they are slow at replying.

I recommend giving a polite nudge at first. A mail along the lines of “Thanks very much for taking the time to interview me the other day. I had a good time and am very excited about the prospect of working with you. I look forward to hearing from you.”

The Good
If the company liked you and wants to hire you, then they’ll likely want to check your references before making you an offer. If they take a long time with any particular stage (e.g. more than a week), then polite nudges are recommended.

The Bad
Almost everyone gets rejection letters at some point. The key here is to use it as a learning experience and move on, don’t be upset and get depressed. It doesn’t necessarily mean that you were bad, there might have been a stronger candidate, the position might have disappeared due to team restructuring, they might have been after someone with very specific skills/experience etc.

What can you learn?
  • Take another look at your resume. Is there something you should add or remove? E.g. Perhaps they liked it when you mentioned that pong game you wrote, and it’s not on your resume.
  • Work through the interview questions again. Research the best answers. Make little test programs which implement the solutions to the problems.
  • How did you cope with doing answers on a whiteboard? Could you practice this with friends/family in some way?
  • If you’d been sat on the other side of the interview table, how would you describe the impression you gave?

Don’t take the rejection too hard - when I applied for jobs in America, five places didn’t even return me a mail (thanks guys:), and then the sixth hired me. Just don’t get bitter, keep coding, and learning from everything you can.

Sunday, September 24, 2006

Moonpod Developer Diary

Before working at Heavy Iron, I worked at a small doomed games company in England called Rage. After our studio was closed as a cost cutting exercise I came to America. A few of my other friends started Moonpod. Since then they’ve released a game called Starscape and are currently in the final stages of their second game 'Mr Robot'.

Moonpod write a monthly developer diary, which talks about what they’re working on, shows lots of pictures, and discusses the issues they’re facing. I find it a great read, and highly recommend it to any novice or professional game programmer.

Monday, September 18, 2006

Tools - Distributed Compilers

You might have guessed by the amount that I talk about speeding up compile time, that compilation time becomes a big problem when working on big projects. A full rebuild of something could take 15 minutes or more depending on the project, machine speed etc (though most builds are a lot smaller). Multiply this by the number of programmers, and you start to have serious amounts of wasted time.

The techniques I’ve mentioned in the past help speed things up, but there’s also a tool solution. Commercial products like Incredibuild (for VC++ projects) and SN Systems DBS (SN make compilers and tools for console development) work by sharing the compilation across several machines. Let’s say there are 8 programmers. At any one moment, usually only one or two people are compiling. When a person compiles, it farms out individual cpp files to the different machines, and they compile in parallel.

There are eventually diminishing returns to the parallelism due to the amount of coordination that needs to happen, and the fact that linking is still done by one machine, but overall a good speedup can be attained.

How do these systems work? I’m not entirely sure about the internals, but my suspicion is that the PC which initiates the task does all the preprocessing of the cpp file, so that all the headers are already included. This means that one file can be moved to the client, and that the file doesn’t ‘need’ anything else.

The downsides are the cost of buying, and the reduced amount of time for juggling.

Friday, September 08, 2006

These are a few of my favorite things...

I’m going to take it easy this week, and just mention a few sites which I like to watch. - Blog about physics based games. - Blog about indie game development. - I was just introduced to this recently, but it’s quickly becoming a favorite. Geeky humor.

Tuesday, September 05, 2006

Game Career Website

Gamasutra have launched At a quick glance, it looks like it's worth a read.