divillysausages.com

Tips for finding a job in the industry

With my current and last few jobs, I've found myself in the position of having to vet CVs and example code to find programmers to hire. Are you looking for a job at the minute but aren't getting much luck? I'll try and present the most common things that I find wrong with applicants that come in to us. These are just my opinions, so I can't say that it's like this for every company (even my current company), but some feedback is better than none, right :D? For the most part, this is advice for people applying for a programming job, but some of it it universal. On a side note, we're hiring - jobs[at]villagemedia[dot]com - so if you want to work in Flash games in Paris, get in touch.

NOTE: some of this may come off as harsh, but this is what it's like on the other side of the fence.

1) Make sure you're applying for the right job

This may sound like a no-brainer, but I feel obliged to mention it because it happens. A lot. If the job is for a gameplay programmer, don't throw your CV in if you're an artist, designer, web specialist, or a sound guy. That's just wasting my time and doing you no favours. This is worse in France where the standard is to send a long email extolling your virtues, abilities and what schools you went to, then add your CV as an attachment almost as an aftersight. I don't want to invest 20 minutes of my time to find "artist" snuck in the bottom of your CV. For smaller companies that don't have a HR department, this can easily add up to kill your day. I do have other things to do.

That said, there's nothing wrong with sending in an application on the off chance that the company is looking for that position. Just don't hijack a specific listing.

2) Your image

If you're including a photo with your application - not a bad idea, but it's not something against you either - try to look like you enjoy life. A smile goes a long way.

One thing to keep in mind, is that one of the first things people will do when getting your CV is Google/Facebook your name. Perhaps it's not strictly speaking fair, but you can be sure it happens. So that said, learn how to work the Facebook privacy settings (a daunting task at the best of times), or make sure there's nothing up there that you wouldn't mind your grandmother seeing. My brother could probably learn something about that.

3) Dial down the formality a bit and keep it real, yo

This might be particular to France, but if you're sending in a cover letter, keep it casual. The games industry is a lovely bunch of people (honest :D); you don't need to impress us with your thesaurus. 100% of the time, I will pull for someone that's reasonably skilled, open to learning, and is someone I want to work with, over someone who's a technical master but a social black hole.

It also seems to be a very French thing to have sentences like "Motivated and hard-working, I..." in your cover letter. This isn't This Is Your Life here. The LinkedIn blog also has a great list of other over-used words and phrases, like "innovative", "results-orientated", or my personal favourite bullshit word: "dynamic". Perhaps you're advised to put this in your CV like it's filling an imaginary checklist or something, I don't know. Know that this comes across as very shallow; a rich person doesn't have to tell other people that they're rich. To get an idea of what this is like, take a look at the singles ads in your local newspaper. Yeah... that's right.

4) Be honest about your abilities

Please don't say you're a master of a language unless you really are. Saying that is a one way ticket to getting stung with the worst questions that we can come up with in the interview. There's nothing wrong with admitting ignorance provided you're willing to learn.

For a Flash programming position, you should be able to answer questions on networking, how the garbage collector works, how the event model works, the OOP model, XML, and the difference between common classes (Shape, Sprite, MovieClip and Array, Vector, Dictionary, Object).

For a Java programming position, you should know: how the garbage collector works; threads; synchronisation via synchronised key words; and how memory allocation works (as in can you explain the difference between int[] intArray and intArray = new int[10].

5) Personal time and experiments

This is only valid if you spend your personal time working on code or projects. It's perfectly fine to have other interests (in fact, it's encouraged), but if you make games in your spare time, or you write amazing, informative blog posts *cough*, then show it off. This is a good thing.

By the way, it doesn't matter if your game has programmer art, or it's just a prototype, show it off. Prototypes show that you're willing (and able) to crank out something quickly to test an idea. For these types of things, I don't really care if your code is a mess (in fact I don't even need to see it). Prototypes are a hack job; failing, iterating and searching for an idea as quick as possible.

6) Show your work

If you're an artist and you don't have a website, forget about it. There's no excuse for not having an online portfolio. Sign up for a free Blogger account, anything.

If you're a coder, pre-empt the question and send in samples of your code. You don't need to send in the entire source code of your game - I don't have time to work through it. Pick one or two examples and send them in. If it's part of a team project, point out your part.

Don't send me links to a game that I need to install or set up an account with. I don't have the time or inclination to manage 100 different accounts in games I'll only play once. YouTube it.

Note: One important thing I feel like I should mention here, is to make sure that you're actually allowed to show off what you're showing. Showing proprietary code (even if you made it, it belongs to the company), or showing work from a project that hasn't been announced, is a short route to my bin. It means you can't be trusted. Always, always, get permission. If this is your only work, then write something in your spare time specifically to show it off.

7) About the work that you send in

Like I said, I don't need to the entire 100+ files to your project. I don't need to see how in-depth your knowledge of the language goes - that can come later in an interview. Don't send me your implementation of a neural network if I can't compile it and see it run either. Unfortunately I don't have the ability to read the half of the files that you sent and compile the result in my head. For the most part I just want to see what your style is, to see if I can work with you without worrying what you're doing or if I'll find myself debugging and redoing a spaghetti mess in a few months time.

The code that you send will be read by whoever's in charge of that area. Any ActionScript that we get goes to me, any JVM code goes to the CTO. It's rare that you're going to come out with something that either of us haven't seen before (I mean stuff that we haven't seen before in the good sense. I've seen plenty of WTF code). That means that we're probably going to notice more things wrong with your code than right with it. That's just the nature of developers: show them a piece of code and they'll turn blue in the face telling you a better way to do it. That said, these are the most common problems we have with code coming in (in no particular order):

8) Congratulations! You have an interview

Well done. You passed the first barrier and your profile is sufficiently interesting enough to warrant an interview. What can you expect? In fact, we're only looking for 2 things during an interview: the depth of your knowledge on the subject (expect to take a test), and whether or not you're cool enough to work with. Of those two, your personality is by far the most important thing.

So what sort of things can you do to help your interview?

9) Afterwards

After the interview step, you'll either get an offer or you won't. The length of time to find out depends on how many other interviews are going on at once, but generally you should have an answer within 2 weeks. If you don't hear anything, follow up with an inquiry email. If you still don't hear anything, then assume it hasn't worked out. Personally, I prefer to let everybody know one way or the other (it's common courtesy after all), but not everybody's the same.

If you get a negative answer, don't be afraid to ask what went wrong so that you can learn from it. Just take the criticism with a good grace; remain polite.

Fin

These are just some of the points that have been floating around in my head the last while. Some of the things that stop people getting jobs are so common that sometimes I wonder if people are just getting taught the wrong thing in college. In any case, if it was all TL;DR for you, the two most important point are: be a clean coder - I want to know that I can rely on your code - and be a fun person - I want to know if I can work with you. The latter is especially important for small companies, where one bad egg can buzzkill the entire office.

If you can't find a job that you like, then make your own work. Everything that you need to make a Flash game is freely available on the internet so you don't have an excuse. The experience you gain will be invaluable, you'll have great pieces to show off (motivation counts for a lot), and maybe you'll be able to make a living off of it. Don't under-estimate the seduction of being autonomous.

Comments

James

All I can say is "thank you".

Submit a comment

* indicates required