Job Hunting Tips
As a former game dev lead and now as a studio head, I look at a lot of resumes.
This is by no means a comprehensive guide, but if you’re looking for a job here are a few quick tips I can share from my own perspective from the hiring side. These are some of the top things, good and bad, that I see every day when I am evaluating potential candidates.
[Required disclaimer: This is just my personal opinion on hiring practices, not official policy for any company including my own! Different hiring managers use different criteria and techniques. Use your own best judgment when preparing your application.]
– Have a demo reel, portfolio or code sample. I can’t emphasize this enough. I’m going to be dead honest: I generally watch reels all the way through before I even open the attached resume. I may even watch your reel before I read your name. I don’t care how many years of experience you have if your reel is crappy… and vice versa, I’m more likely to give someone with little or no experience a shot if they have a really brilliant demo. In the end, we want to hire people who can produce a superior end product regardless of how you acquired your skills, and the best way to prove to me you can do that is to show me a great example of an end product.
– Your demo reel only needs to show what it needs to show. Or, to clarify: if you’re an animator, a reel with untextured characters or stock textures–as long as they are credited–is perfectly okay. If you’re a programmer, a well-written class file is enough. I don’t need to see a whole game or movie. I just need to get an idea of what you can do. In fact, this is especially true for programmers. Many programmers send compiled binaries and no source code. A compiled binary doesn’t tell me very much. I’d much rather have a sample of well-written code even if it doesn’t compile because the rest of the app is missing than a pretty demo with no source and no idea if it’s a rats nest under the hood.
– If you are a programmer, comment your code. An uncommented demo is an instant fail. If can’t bother to comment your demo why would I believe you would comment your actual source?
– Write a cover letter. It doesn’t have to be long or elegant; in fact, it’s better if it’s brief. Give me the “highlights reel” before I view your portfolio or resume. Tell me the one or two very best things about yourself that make you a better candidate for the position than anyone else. It gives me an idea of what you think I should focus on when I read your resume.
– Don’t call my desk line, but it’s okay to send me an e-mail even if we don’t have a job listing posted. It’s not that I don’t want to chat, it’s just that I’m much more likely to be frazzled and in the middle of something if you call me unexpectedly. [Edit: For clarification, I mean cold calling. 🙂 Regular calling when I expect you might is okay, naturally.]
– Freelancers [sometimes] have better chances of getting work, especially if they aren’t looking for full-time. There are two reasons why freelancers are desirable: The games industry is very seasonal in nature with lots of ups and downs. We may not have enough work or the budget for a full-time employee, but we may have specific projects that need done. (And, oddly, small projects often have a way of leading to more work…) Secondly, hiring people is just darn hard. It’s heartbreaking (really) to hire someone who doesn’t work out, and nobody likes doing it. Contracting is often a good way for both parties to see if the other will be a good fit. If it turns out there’s a ton of work to do, you love what you’re doing, and we love your work, then when a full-time opportunity does present itself it’s a much easier jump. Now to be fair, I know contracting is not for everyone so it’s by no means a requirement, but if you were thinking of freelancing already it’s worth considering. ** This tip may or may not apply to certain companies. Some companies never hire freelancers. We use freelancers frequently.
– If you send your resume as an e-mail attachment, put your name or something identifiable in the file name. Don’t name it “resume.doc”. “jane_doe_resume.doc” is much better. Resumes always get saved off to disk before reading so they can be virus-scanned first. Putting your name in your resume file name makes it stand-out when someone is searching through the folder of virus-scanned resumes for yours.
Tags: artist, game dev, game development jobs, hiring, programmer, resume, video games
August 7th, 2009 at 3:57 pm
I would just like to question the following “If you are a programmer, comment your code. An uncommented demo is an instant fail. If can’t bother to comment your demo why would I believe you would comment your actual source?”
Because we do not generally, I mean programmers are taught to write code that does not require comments so that code speaks for itself; unless there is something unusual going on. This means giving variables, objects and constants etc meaningful names whilst not using magic numbers. The problem with comments is they become out of data and sometimes (read a lot) do not reflect what the code is actually doing, therefore they are more harm than good.
August 15th, 2009 at 11:50 pm
Ste, the reason why comments fall out of date is because of poor programing practices where developers refuse to treat the comments with the same level of respect that they do to the code. Comments should be explaining *why* you’re doing something. The code itself should be clear enough to explain *how* you’re doing something by its structure.
In my own workplace I require all of my developers to not only comment their code but generate written documentation to complement the code within our project support wiki. The idea is to provide a complete array of documentation so that another team can come in and pickup where we left off by knowing why everything was done in a particular way. This has unquestionably improved the ability to hand off complex projects between teams.
August 17th, 2009 at 6:29 am
“Comments should be explaining *why* you’re doing something. ”
I could not disagree more.
Martin Fowler “Comments often document assumptions about how a piece of code works or how it should be called. When you see those comments, or feel like writing one, think about how you can turn it into an assertion instead.”
Bjarne Stroustrup “If something can be described in the language itself, one should do that, and not just mention it in a comment.”
It sounds like your functions are doing too much and maybe you should look at the Single Responsibility Principle or Abstraction then the function names explain the why or simply you do not need to know why.
November 2nd, 2009 at 9:43 pm
Good tips! – although your view on comments is in my opinion incorrect.
The code should explain itself, if you need to add a comment to explain why, then the code needs to be refactored because it is confusing. See ste references. Might as well add code complete in there 🙂
November 10th, 2009 at 4:41 pm
bz/ste, I appear I wasn’t clear in my thoughts. When I say “why” I mean something like this example:
“This approach was used because of a business requirement to collect this data through a previously existing shell script (called below). Currently the DB team also calls this shell script and this prior use is used as a justification to avoid a re-write. If you are maintaing this code and observe that the DB team has ceased using the shell script (this can be observed by examining the output folder for daily activity) we should confirm and then consider incorporating the script functions into the master program for performance improvements.”
September 24th, 2010 at 10:59 am
Bryan
My husband is a programmer….at the school/college he first learned to program he was taught to document everything whether it needs it or not. Comment, comment, comment. For the same reason you just gave to Ste. He has been working on some code for months now that would have been a whole lot easier had the people who coded it, documented it. It helps make things go faster when updating and making changes or even languages.