Part 1 looked at what qualities you need to get in, while in this second half I’m going to be looking at the application process – from CVs through to interview. You need to get both parts right: obviously polishing your CV and preparing for an interview isn’t going to make up for missing skills – you might get a little further along if you’re lucky, but you won’t get in. The real shame, however, would be for a highly skilled person to submit a weak CV, or prepare poorly for interview – because this part is so easy to get right. I might see through to your true abilities, but I might not. Do you want to take that chance?
Hunting through rubbish
I really need you to understand how easy it is to be overlooked. From my point of view, the CV filtering process is like searching for something valuable in a big old pile of rubbish.
We get a lot of CVs. I don’t keep figures, but more or less all of them are terrible. I have plenty of other things to be working on, so I’m in a hurry. Like anyone who does the same tedious job repeatedly, I’ve developed reasonable heuristics to do it efficiently. The problem for you is this:
There isn’t really much penalty for me missing a good individual, or at least if there is, I get no feedback on it, because by definition, I have no idea when I’ve missed someone good. On the other hand, there’s an obvious penalty for me allowing a poor candidate to the next stage. I quickly find the problem at interview, and try to avoid wasting my time like that in future.
In other words, I naturally develop ways to discard rubbish quickly, while spotting just enough valuable stuff to fill my vacancies – which is very different from having a way to find as many good candidates as possible. That’s just me being pragmatic and effective in the face of time pressure, sorry! The good news is that it should be simple to get past my heuristics, in 4 easy steps🙂
Step 1: grab attention
Your first job is just to get my attention. I’m moving quickly through a big pile of CVs, spending maybe 30 seconds on each one, so your first goal is just to slow me down slightly. I’m going to spend slightly more time looking at something that’s visually interesting – if you can push 30 seconds up to 45, you’ve got a significant advantage.
I know you’re a programmer, so I’m not asking for anything fancy, just a clean layout that’s visually strong or has something slightly different about it – perhaps a combination of fonts, perhaps some strong visual alignment, whatever. I did get one with a bright pink background once. That slowed me down, but in the wrong way. Some companies mangle your CV through some weird automated tools and recommend you just send a plain text file. Actually, we don’t – so I’ll see the formatting as you intended it (strangely, in all the many CVs I’ve seen, I’ve never had a plain-text one: if you’re the type of grouchy programmer who hates the idea of doing anything remotely aesthetic, you could actually catch my attention with that! ) The vast majority of applicants send a Word document with the default font throughout, a depressingly average layout with centred headings, no contrast, no alignment, nothing, so the bar is not set particularly high here. I can’t recommend this book enough for a very simple introduction to good page design (it used to be purple):
Step 2: be perfect
Remember what a hurry I’m in? I’m looking for a reason to move to the next CV – and any mistake will do. Review your CV over and over. Get someone else to do it too. Get your spelling, grammar and punctuation right. You just sent me a Word document with spelling mistakes that Word’s spellchecker is picking up? Next! Get your technical terminology right. A classic pet hate of mine is people who say they’re good at “object-orientated design”. Here’s what Google has to say on the topic:
Did you mean: object oriented
Yes Google, you did. Next! Here’s the best CV blooper I can remember – right at the top, starting their personal statement with
I have always been good at innumeracy …
Step 3: show me what’s good
You’ve got my attention, and there are no mistakes to be found on skimming the page. I’m still reading quickly, so now you need to draw my attention to the good parts, which may include some but not all of:
- Jobs history
- Anything else relevant: projects, open source contributions, …
- What you’re passionate about
- What you’re good at
- Why you’re applying
In each case, I’m looking for something personal, something original, something interesting that shows you’ve put some thought and care into it. This is where I might just start to like you. If you’ve had a programming job, tell me what you did – something you’re proud of. If you’ve just had typical part-time student jobs, they may still have taught you something, perhaps in people skills if not technical. Write specifically for (someone like) me, rather than making a generic CV that you’re shipping off to hundreds of places (“I’m looking for a job in IT …”). Just listing your grades and employers in a matter-of-fact way is not going to impress anyone. We get hundreds of CVs like that. You have to put the effort in to sell yourself.
Step 4: what not to do
A couple of final things I hate:
- Lists of technologies. I really hate these. If you’ve done the previous part properly, I’ll know what knowledge you have to what level in your previous jobs, education or open source work. Anyone can spout a list of technology names, and anyone can have a passing acquaintance with them. I want to know about serious, impressive pieces of work that you’ve done with them. I want to know a bit of depth and detail about this. If you’re not good at it, don’t mention it.
- Cliched stuff like “I have great attention to detail” (especially if your CV doesn’t reflect that!!), “good communication skills” or “I’ve always wanted to get into games”. Anyone can write vague phrases like these, and almost everyone does; you can and should do better.
To demo or not?
Submitting a demo is a time-honoured way to get your first job in the games industry. As far as I’m concerned, you’re wasting your time. Here’s why:
- I’m in a hurry – running a demo doesn’t fit into my 30-second CV scanning, so you’re either in or out on that basis. If I like the CV, that’s enough to move to the next stage, so I’m unlikely to bother with the demo.
- I’m not wild about running an arbitrary executable that’s been sent in.
- It’s unlikely that you’ll build anything that great, let’s be honest. The amount of work that goes into modern game technology is massive, and one person isn’t going to achieve much, particularly if you don’t have art or music skills – you could end up with great code let down by poor content. At best you probably produce something along the lines of a polished old-school game, which tells me absolutely nothing about your ability to work on one of our large, complex projects.
- I’m more interested in the code you write than the final on-screen result.
Having said all that, there are many companies (primarily the smaller ones) that still value them, so it may be worth creating one for their sake.
The standard forms
As well as the CV, we usually ask people to fill in some standard forms and sometimes answer a couple of written technical questions. There’s not really much to worry about here, and I won’t say too much as the forms and questions are liable to change over time. Some hiring managers like to lower the bar on CVs very slightly and use the technical questions as a way to filter, so it’s not an opportunity to shine, more a chance to screw up. Whatever you do, compile and run the code you submit – otherwise you could really look stupid.
One of the forms also asks about salary expectations. We don’t really do salary negotiation, so there’s not much point treating it as such by entering something artificially high (and conversely, don’t worry about putting in something too low – we won’t take advantage of you). Mostly this is there to make sure we’re not wasting our time with someone who thinks they’re worth way more than we do.
Phone screen and interview
If I like the CV, it’s phone screen time. The technical part of this is really simple and nothing to worry about – never more than half an hour. I’m not going to give you any clues about the questions except this: if you can’t answer them quickly and confidently, you don’t deserve a programming job anywhere. The point is, CV filtering isn’t perfect, and I’m still trying to weed out junk efficiently, just using a slightly different perspective.
In non-technical terms, it helps to prepare in two very basic ways: make sure you know at least a little about RTW and the job you’re applying for (if you don’t seem interested then I’m unlikely to be), and come with a few reasonably engaged questions about us or the job – again, showing some interest🙂 This applies to both phone screen and face-to-face interview.
For the interview itself, just remember my previous post and the three things we’re looking for. Apart from preparing for standard technical stuff (like basic algorithms and data structures), the most important thing you can do is to have a significant piece of work you can explain in depth. I’m going to be looking for:
- How tough this was – I’m going to drill down into what you did, specifically, and what the hard problems were. I’m not going to be impressed if it turned out that the other contributors did all the hard parts and you just added some cosmetic bits and pieces.
- How well you can explain it to me – the problems you faced and the solutions you created.
- How much you cared about it, which comes across by how excitedly you talk. If I ask you to describe the work you’re most proud of, and you can’t make it sound interesting, it doesn’t say much for your level of engagement in your work.
This is incredibly important and well worth preparing in advance. A surprising number of people pick a project which turns out to be dull or easy when I drill down into it.
There’s one unfortunate fact of interviewing, which has already been coined the “interview anti-loop”:
We eventually concluded that every single employee E at Amazon has at least one “Interview Anti-Loop”: a set of other employees S who would not hire E
This phenomenon is alive and kicking in the games industry. There’s often a generation gap between older game programmers and younger: people who rate assembler skills and people who don’t care, people who think the C++ standard library is the root of all evil, and people who think you’d be crazy not to use it. I’d say in general our interviewers lean more to the modern style, but there are some exceptions, so beware! I’ve seen candidates obviously trying to get around this by trying to say what I want to hear rather than what they think. This is pretty daft – it’s transparent and can easily backfire when I ask you to justify and explain your position and it turns out to not be something you believe in. Be yourself and say what you think. The anti-loop, I’m afraid, is just tough cheese.