Advice for applying to game developers

Advice for applying to game developers

By Robin Green

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.]

1. Don’t "lie" on your CV. Not even half truths.

What happens is this: We get a pile of CVs from recruiters and direct applications. We read every CV looking for people to fit the posts we have open. On the basis of your CV, we write back and ask you to visit. You will be dragged down to our campus starting at some god awful hour of the morning. We too as interviewers will come in early. We will go through your CV and ask you questions like whether the reference to C/C++ in your CV means "C but I once read an article about C++ in Byte" or whether you actually know the language. If you say you worked on a project, what areas were your responsibility? So, you worked on that 2 million seller, but you did the high score table as a summer intern? You say you have "considerable knowledge of Game AI", but you haven’t heard of A* or Finite State Machines? You say you "have experience in assembler" but never got beyond 8086 segmented architectures and that was 8 years ago?

You will then go home, not get the job and have wasted your time and ours. We asked you to visit as a possible game programmer in our new market breaking thriller, you go home as a bewildered kid out of your depth and out of pocket because you "exaggerated a bit" on your CV.

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.

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.

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.

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)

Robin Green has been Research & Development programmer for Bullfrog Productions for nearly 5 years and is also responsible for taking part in the interviewing process at Bullfrog.

This article has been taken from a newsgroup posting.

Discuss this article in the forums

Date this article was posted to GameDev.net: 8/2/1999
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Getting into the Industry