5 Resume Tips for Total N00bs to Land a Job as a Game Programmer

Post GDC we received a lot of resumes. Which means that my team has to spend a lot of time going through resumes of game engineers and deciding which to follow up with, and which to pass on. And because of the high student population at GDC the majority of these resumes were from students with no professional experience of any kind. So how do you decide the fate of someone based just on a quick glance at a summary of their life?

You really can’t know for sure, resume judging is a black art more than a science. At some level it is just a roll of the dice and a hope that you dont critically miss. The only way for me to truly judge these canidates would be to talk to them, and to spend time with them. Unfortunately, that is just not possible with the amount of interest we get, and the field of applicants needs to be culled.

The good news is, that even as a green student there are things you can do to make your resume stand out, and with the right preperation, and a little luck you can survive the bloody battlefield of resume sorting and find your way to the phone interview.

1. Projects. Projects. Projects.

We all know the classic catch-22: no job without experience, but no experience without a job. Fortunately, in the game industry there is an awesome loophole: you don’t need a job to make awesome games!

Make sure to provide a link to a website where your projects can be viewed. Videos, screenshots, and game downloads that showcase the games you have made are what convince me that you are a hotshot worth wooing.

Don’t have any projects? Well get on it! Its never been easier to work with the same tools the big boys are using, UnityEngine has a cheap student license, Half-Life and Unreal have a very active Mod communities, and the XNA framework is just awesome for creating XBOX and PC games. This is how I got my start in the game industry, and this is still the easiest way to impress me with your resume.

2. The importance of your school.

So this might be a little hypocritical coming from me, as I never finished my degree! But, a hard science or engineering degree can go along way, especially if its from a top school such as CalTech or MIT.

The game development specific schools out there are a mixed bag. Their hard math and science regiment isnt as in depth as a tradition school, but they have the huge upside of getting to make actual games. With people who went to these types of school I am looking to see if they took a leadership role in any of their projects. Lately, Ive been seeing a lot of resumes from students of the game development schools who just list the projects on their resume with a short description of them and no links for more details. Don’t make this massive mistake! Without being able to see the actual projects you are working on its almost like you didn’t even do them, make it easy to check out the cool work you did!

3. Focus on your specialty.

You really want to work in the game industry, so much so that you would be willing to take any job: Coder, designer, producer, heck even getting coffee! Your passion is awesome, but this lack of focus can be  poison for your resume. Pick what you are really good at and go after it, showing that you know what you want and have been focusing on learning all you can about it.

Even as a student I like to see programmers who have deep-dived into some area of expertise. Highlight the graphics programming you did on one of your projects, or the awesome tool you built to design content faster, or the gameplay systems.

This doesn’t mean you are doomed to be pigeon-holed, it means that your potential employer can envision exactly what you will be contributing from day one. If I find someone who is really smart in a few key areas, I know that they can learn other areas and branch out. But, when someone is just mediocre in a lot of things, I am much more likely to pass them over.

4. Highlight your achievements.

When looking at your resume I am looking for signs of an overachiever. If your game projects have won any awards or received any special notice make sure to call this out. But, even non game specific stuff that you really kick ass at is important to show off. Maybe you have a black belt in Karate, you got to world finals in Magic: the Gathering, or you were Editor in Chief of your school paper. Let me know about these things and I am more likely to give you a second look.

5. Keep it short and sweet.

Keep your resume short: one page or less. A short resume forces me to focus on exactly what you want me to see. Leave off the stuff that is not relevant and just not flattering. I really dont care that you flipped burgers at Jack in the Box, or were a waiter at Olive Garden, this stuff is not showing that you have a work ethic, it is just sabotaging you’re chances of getting an interview by distracting from the important stuff on your resume.

You can also lose the long list of skills that lists every single programming language you’ve ever heard of and every software package that comes installed with Windows. Listing “Microsoft Word” on your Resume is not impressive, and unless you can answer in depth interview questions about all of those programming languages that you listed you are just going to make yourself look bad during the phone screen. Remember tip #3, focus, and pair that list down to just what you are really bad-ass at.

Best of GDC 2011 — Talks and Lectures and Cheese*

Just got back from GDC 2011 and had an amazing time.

As always I have come back from GDC feeling inspired. Talking to people at the top of their game, pushing the envelope on game development always starts a fire in me to do the same. At no time do am I more excited about coming into work every day than the weeks after the GDC.

My favorite lectures this year come from the excellent engineering team at Bungie. Their lectures were both interesting and very practical, their engineering team is extremely open with the game development community, which leads to better engineers and better games for everyone, which is only a good thing for our industry.

On to my top 5.

1. Networking the gameplay of Halo: Reach

by David Aldridge of Bungie

http://schedule.gdconf.com/session/12126

David took us through his journey of updating and optimizing the network code for Halo: Reach. We got some cool videos of their profiling tools, which allows you to visually inspect any object in the gameworld to see exactly when and how the engine  sends packets over the network. This allowed Bungie to do a ton of fine tuning on a per-object basis. For example, this visualization caused them to notice an anomaly in dropped weapons and they reduced their entire network bandwidth by 10% simply by adjusting the rate at which weapons slid down hills!!

One of the most interesting innovations was the addition of a “lag button” in playtests. They instructed their testers to press this button whenever the game felt laggy. They could then take the replay and fast forward to these points in order to debug the networking. What they found was that players were pressing this anytime something confusing happened to them in the game. If they got killed from behind quickly and the deathcam didnt show the killer, they would press the “I Lagged” button. From this they were able to fix game design issues they had never noticed before. I love this idea and I am definitely stealing it!

Unfortunately, he only spoke briefly about how to predict bullet-based insta-hit weapons which is a really interesting talk I hope he covers in detail at a future GDC. However, there is a great article on how Valve tackled this problem from 2001 available here: http://tinyurl.com/coljwf

2. Halo:Reach Special Effects

by Chris Tchou of Bungie

http://schedule.gdconf.com/session/12127

Only 25 minutes long! Yet packed to the brim with awesome stuff. A highly technical lecture that Chris made easily understandable. A particle system that runs completely on the GPU packing basic particle state into a texture. Using the depthbuffer to handle particle collision allowing for completely GPU-based bouncing rains and sparks! 

3. Iterating on a Dynamic Camera System

by Phil Wilkins of Sony Santa Monica

http://schedule.gdconf.com/session/12364

Another lecture that just had a ton of practical, useable techniques. Phil took us through the history of the God of War camera from its first iteration in God of War 1 to the final version that shipped in God of War 3. The camera system starts by taking designer placed nodes around the map that are near the action, and blends them together to get a final camera. The combat system then puts in its two cents and modifies the camera to perfectly frame the action taking place in the scene.

Usually defining the rules for a camera system is the easy part, its all the little edge cases and gotchas that really make it difficult, and Phil walks you through several of these edge cases that they ran into, making this talk especially valuable.

Phil’s original lecture is available here: http://web.cs.wpi.edu/~rich/courses/imgd4000-d10/lectures/camera.pdf His updated lecture for God of War3 is not available yet.

4. Forensic Debugging

by Elan Ruskin of Valve

http://schedule.gdconf.com/session/12129

This one really opened my eyes to a lot of interesting debugging techniques. Taking us deep into what the compiler actually does with your code, Elan stressed the importance of understanding some basic assembly in order to track what was actually happening in your release executable. At one point the audience gasped when Chris revealed a stack trace in which the callstack was completely corrupted, that the pattern of the corruption formed the letter “A” if you looked at the memory just right, revealing a problem in the font code! Unfortunately, Chris moved a bit too fast for me and left me in the dust a bit. But thankfully, he posted his slides up (http://tinyurl.com/624efkf). This is one of those lectures that I’m going to be spending a lot of time going back through and reading on to try and fully grasp.

And the one that surpised me the most:

5. Industry Lessons Learned

by Cliff Bleszinski of Epic

http://schedule.gdconf.com/session/12352

I didnt know what to expect for this lecture, but it ended up being very entertaining and inspirational. Cliff talks of the idea of a “Power Creative”,  a developer who is highly visible, highly active, and plays a leadership role on their team. He encouraged more companies to nuture and grow their own Power Creatives, and expressed concern that he had never met a developer from Rockstar, despite all their successful games. He also stressed the importance of understanding how to sell, pointing out that every great idea has to be sold first to your teammates, then to your company at large, and then to the public, so it is a very valuable tool to possess even for those of us in the trenches.

–

* The cheese sucked