Advice for applying to game developers

After giving a load of interviews recently I've got a few pieces of advice for prospective candidates:

[NOTE: CV, or Curriculum Vitae, is used instead of a 'resume' in Europe.]

[size="5"]1. Don't "lie" on your CV. Not even half truths.

[size="5"] 2. Keep your CV clear, truthful and up to date.

Be prepared to defend every statement in it and be able to provide proof that you can do what you say you can do. Because, trust me, we will ask.

[size="5"] 3. Have at least one clue about the job you've applied for.

Having a clue about the job you're being interviewed for does help, really it does. Some knowledge over and above what your mate once read in Maximum PC or Edge Magazine, some idea how games are made and how the industry works is valuable. A clue or two about game teams, producers, alpha, beta, gold, source control, design docs, artists, file formats, basic math and the current state of the art. That should get you through the first half hour of the interview.

After that you should be showing us where you excel, what really excites you about programming, where you're special and why we shouldn't just say "Well, it's been great. You'll be hearing from us by the middle of next week", see you out of the door and go off for a coffee.

Think about your CV, your application letter (those are getting rarer and rarer these days) and the job you're applying for. Don't just let the recruiter send you everywhere because, to them you are just a piece of meat with some redeemable market value. (With the exception of some agencies such as Walter & Company). They will send you round the houses until you get a job and they get a fee of 10% of your starting salary for the cost of a few faxes and phone calls.
[bquote]I recently applied for a job with a game company. They first gave me a three-day programming assignment via email, and then called me for a phone interview. I'd suggest you do something similar, as it saves everybody time and money. [/bquote]
We have done something like it in the past, and Pete Molyneux was famous for setting his "Pentominoes" problem as homework. The problem with remote interviews is that is that our interview technique is not about getting right and wrong answers. We're interested in how you think, whether you're open to cooperative problem solving and exactly how far we have to push you before you say "I'm sorry, I don't know that" (some people never do admit to weaknesses and think BSing their way through will get them the job).

The interviews are shaped by the interests of the candidate. If you want to sit there and have a discussion on the state of the art in line-of-sight navigation, fine, we'll do that. If you want to discuss the relative merits of compilers, we'll do that too. We'll also ask questions in the exact opposite direction - you're a low-level assembly hacker we'll ask you about Abstract Data Types. You're a high level MFC "user", we'll maybe ask a question about efficiency and compiler optimisations or maybe cache coherency.

It's about how sparky the person is, how interested they are in what they do, whether they're mature enough to handle intense teamwork and whether or not they've got a broad enough base of experiences and all-round computer knowledge.

Companies that just sit there and ask questions like:

a) So, what's your dream game?

b) What's the best bit of code you've ever written?

c) Where do you see yourself in three years?

d) What are your weaknesses?

will fill up people who just feed back to you what you want to hear. We require a little more.

P.S. the correct answers to these questions are:

a) Whatever genre their current project is. Plus a bit.

b) My last one. I get better all the time.

c) Leading your next, next project.

d) Well, I'm a bit of a perfectionist (if you've ever seen Trainspotting)