I hadn’t really anticipated adding a part 3, but I gave a talk at Abertay last Friday on the topic, and need to make the slides available for anyone who missed out, or who wants to follow up on some links etc. So, here they are. It’s similar material to my previous two entries on the subject: part 1 and part 2.
A couple of slides may need some explanation if you weren’t there:
- At the start, I compared a CGT graduates’ chances of getting a job with us to those of the Ivory Coast winning the World Cup. I was, of course, being totally flippant and very unfair, but hopefully it did the trick of (strongly!) making a point that was repeated throughout: just having the degree is not enough. The degree is great, but if 30 other people get the same degree in your year, and numerous other games courses turn out graduates at the same time, you need to do something to differentiate yourself.
- The ‘scale’ diagrams show the number of communication paths between ‘n’ people on a project, with n = 3, 9 and 100. With 100, it’s insane!
- The neds are there to show that a love of playing games is little or no help in getting a job. We need people who love making games, and they’re not the same thing.
- The first set of CVs are real CGT examples from last year, with a load of details jumbled around to anonymise them. My main point was that they’re so nondescript, they might as well just have said “I have a CGT degree”. I think Sid Meier won the popular vote on the day, but more or less everyone admitted to not having a clue who was best. Neither did I, which was the whole point!😉
Something I forgot to mention until the questions afterwards: we do have summer internships, and, naturally, I highly recommend them! I think applications open early-ish in the calendar year. Keep an eye on the jobs section of our website. I also didn’t have time to get onto the interview process, but I think that’s the easy part in some ways. The hardest part of all this is putting in the many hours required to gain the skills and abilities we need in the first place. The CV part is there because it’s unfortunately easy to screw up and get overlooked, but it’s really not that hard. Once you’re at an interview, you certainly can’t be overlooked, and if you have the skills we need, it shouldn’t be anything to worry about. I know it may be nerve-wracking, but I don’t think there’s anything useful I can say to improve your chances at that point. Just be yourself and try to relax.
In preparing the talk, I did clarify some further thoughts in my own mind on what makes good content for a CV. You can be very effective by simply stating what you’ve done in a factual manner, with enough specific technical detail to back it up. There’s an example in the slides of a guy who contributed to an open source game engine, and did some coursework on inverse kinematics. It’s impressive in a very understated way, and a welcome contrast to the many CVs that dress up their experience with claims of something being “advanced” or “complex”. If your project is advanced or complex, explain the specific facts which make it so (the inverse kinematics project is a good example). I’ll then be able to see that it’s advanced (or complex). If you say yourself that something’s advanced, you end up in one of these situations:
- If the project is advanced, and you explain why, then fine – you don’t lose out, but then you haven’t gained anything by using the word ‘advanced’ either.
- If you fail to explain why the project is advanced, I don’t have any reason to believe you.
- If I consider the project to be rather simple (which it often is), you just come across sounding foolish – someone who struggles with simple things but thinks they’re really good.
The only possible valid reason for using words like these is to get my attention, but you should do that with the layout, fonts etc. So there’s plenty to lose, and nothing to gain. Just strip out any adjectives that talk up your experience too much. In a similar vein, don’t come out with guff that’s not based in fact. Too many people say stuff like “I have strong leadership qualities” or “I am highly proficient in C++”.
The trouble is, anyone can say this, and without evidence to back it up, I have no way to know what’s true, so I’m unable to distinguish one candidate from another. If you’re proficient at C++, you should probably be able to tell me some specific techniques you’ve used in your projects that demonstrate your knowledge and proficiency level. If you can back that up with some demo code showing it, I can form an accurate judgement of your level. Of course, it’s still possible to fake this by pasting stuff from elsewhere, but I’ve yet to see anyone go to such lengths, so I’ll trust you (I’ll find out if you’re faking it at interview anyway!).
Once you strip away the guff and the boasting, you’re really exposed and it becomes painfully obvious whether you’ve done anything good or not. For some, this may be quite scary; it’s like being naked. It may even be worth writing up your CV in this manner half way through university, with no intention of sending it to anyone: it could alert you to whether you’re on track for having a good-looking CV or not. What’s missing?