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):
- No comments
- Coding in another language
- Bad class layout
- Lousy naming conventions
- Whitespace is your friend
- Magic Numbers/Strings
- Using space instead of tab
- Unoptimised code
- Irrelevant code
- Messy code
This is a massive negative point against you. When we have a posting up, we receive a lot of replies. Looking at people's code takes time; time that I could spend doing something I'd rather be doing. I don't have time to walk step by step through your code to see what's going on. If you have no comments, this is what I have to do. It also means that your code is unmaintainable and unusable in a team setting. When you return to it in a few months time (and you will), it'll take you 3 times as long to pick it back up. For someone else, double that.
Comment everything. And I do mean everything. If you have a bunch of addChild() statements one after the other, put a nice "// adding all the children" comment above them. Why? Because it's quicker to scan the comments to get an idea of what's going on than to read the code and work it out.
Also, if you're only sending a couple of files, add some comments to explain what excluded, but referenced, classes do.
This only applies if you're in a country where English isn't the main language. Why is this a problem? Because the code is not just for you. It can be shared anywhere, everywhere. A mix of two languages slows the comprehension of what's going on. You could argue that if everybody in the company is French for example, then it should be fine to write your code in French. Then watch as that comes back to bite you in the ass. The language that you're using is written in English, so your code should be as well. My CTO is stronger on this point than I am (and he's French). Besides, pere.addChild( fils ); looks ugly :D
Keep your class laid out in a consistent manner. How you actually do it is a matter of style, but don't mix different accessor levels. That's sloppy. Consider also separating the sections with a line of comments like /*********/.
As a matter of reference, the order of declarations I use is public before private, static before class, and variables before accessors before the Constructor before methods. Why is this important? It makes the file much easier to scan and quicker to comprehend.
Keep it consistent. For class variables, I tend to favour prefixing them all with "m_". Why? Because it differentiates them from properties and local variables. For properties and functions use lowerCamelCase. I also like to prefix a "_" to my private functions as it makes it super easy to tell them apart from public ones. If you're coming from Java to AS3, don't use get and set functions (e.g. getName():String and setName( s:String ):void) - use the getter and setter properties. And please don't do something like public function get getName():String {...} (yes, we've had that one).
Name variables something that makes sense. I had one class file that contained about 100 variable declarations and they were all named like f, fa, fa1, fa2, fa2.... Seriously, that's just insane.
This is not a competition to see who can write the most code in the smallest amount of space. Use blank lines, spaces and tabs liberally through your code. It makes it so much easier to read. Which is quicker to see what's going on here?
private var m_myNum:Number=0.0;
private var m_myString:String=null;
private var m_myInt:int=0;
for(var i:int=0;i<someLen;i++)
...or
private var m_myNum:Number = 0.0;
private var m_myString:String = null;
private var m_myInt:int = 0;
for ( var i:int = 0; i < someLen; i++ )
...With a lot of variables or code, this becomes much more useful. I also use this to break up code in large functions and group similar functionality.
If you're using custom events, I don't want to see something like myObj.addEventListener( "somethingHappened", this._onStuff );. If you can't see why that's a bad idea, then I can do nothing for you. Learn to love public static consts.
The same goes for magic numbers. Code like if( this.x > 43.2 )... is an immediate no-no. What's 43.2? Where did you pull that from? What if I want to change it? If I see about 15 references for 43.2 in your code, I will sigh.
This one is a bit of personal preference for me. Some devs prefer to use space, others prefer to use tab. Personally, I prefer to use tab because it's quicker and it's easier to align stuff. If you need it to be less than 4 spaces, then it's a simple editor preference switch. If I see a mixture of tabs and spaces throughout your code, that really only tells me that you've copy/pasted this code from a site somewhere. Which tells me you don't know what you're writing.
Optimisation is an important topic if you're applying for a Flash programming position. You need to have a grasp of the basics at the very least: using Vectors instead of Arrays; taking the length property out of a for loop to a separate variable; multiplying by 0.5 instead of dividing by 2; logic control path optimisation; reusing objects, etc.
Why is this so important? If we're making a resource-intensive game, we'll need every cycle. Even if we're only making a basic game, having the fan kick in on your computer every time someone plays your game is a bad thing. Remember that you'll never have the full CPU; there'll be other tabs in the browser open, iTunes running, Office programs, etc. With the increasing focus on mobile, it's also possible that a game can be ported to a smartphone. Finally, it shows that you've a good understanding of what's going on behind the scenes in Flash.
Remove code from the class that's not used (I've seen 20 lines of local variable declarations that are never referenced) and remove code that's been commented out. If you have a function or a code branch that's 10 lines long and 9 of them are commented out, just remove them. It looks sloppy and lazy.
This point is a bit of a catch-all. The biggest reason why we ask for code is to see what your code looks like. If you're going to be working with us, then we need to know that you can produce well-documented, tidy, easily-comprehensible, easily-modifiable code. If your code is all over the place, then it's not good. I don't want to be bug-hunting in a spaghetti ball where the code is any which way. Keep it neat, keep it indented properly, keep it clean.
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?
- Come prepared
- Relax
- Prepare to explain your past
- Prepare to get tested
Come on time, and always, always bring a) a copy of your CV, b) any work you want to show off (on a laptop). Interviews take a few hours from work that we're meant to be doing. Often, we'll be in the middle of something by the time your interview rolls around, so by bringing copies of a CV with you, it makes my life easier. That can come across as me being lazy and rude, but in a small company, you don't have the luxury of taking all the time in the world to re-read CVs, cover letters, and notes before someone comes in. We have deadlines too ;)
It's almost a cliché to say it now, but seriously, be yourself. Remember, you're also being tested on your personality, so don't be afraid to liven it up a bit. Generally, I find acting like I'm already hired and part of the team to be the best way to deal with it. Please don't be overly formal (polite is fine), or worse, subservient. Know who you are and what you're worth. If I'm getting drenched in pity and desperation vibes, it makes it very hard to like you. Be confident, even if you're not. Confidence is one of those magical things where if you act confident, people will treat you like you're confident, which will in turn give you confidence.
Often, after we've presented a bit on the company and what we do, we'll start going through your CV, and in particular your work experience. Explain what you did depending on who you're talking to. HR or anyone non-technical couldn't care less about the different algorithms that you used (sorry), while if you're being interviewed by a lead (me), you can take a bit of a liberty as to assume I know what you're talking about without going into too much detail. Highlight any leadership roles, teamwork, what you learned, what went wrong and what you learned from that etc.
Please don't bullshit; you'll be caught on it. "I spent 3 months implementing a popup system for this Flash game" = bullshit. I'm also quite happy to say nothing and let you dig your own hole; it's a bit mean, I know, but you'd be surprised what you learn about someone just by letting them fill in the silence.
Expect to explain any holes in your employment history as well. There's no shame in being unemployed - we've all been there, or had a bit of hard luck - but there's no excuse for doing nothing with your time. Use the time to learn Unity, or build a Flash game of your own; anything at all. You could earn yourself a bit of cash as well as having a good portfolio piece for showing off. Perhaps you'll even decide to go indie. The point is to show that you're actually motivated to work. We had one interview where the guy explained a years absence from work by telling us that he mostly watched Star Trek. Hmm...yeah...
It's rare that you'll have an interview without some sort of test of your knowledge. This test will often contain a range of questions, some of which might be outside your ability. That's fine; there's no harm in admitting ignorance - make sure you look for and understand the answer to learn it though. However, if you're faced with a question that you don't know the answer to, don't sit there, hum and haw for 5 minutes, before finally saying "I don't know". Often, there'll be a pisser of a question specifically to see how you react to it. If you try to work out the answer, seek alternative ways, or generally show initiative, this is a good thing. If you're coming from another language, don't be afraid to say "Well, it's like this in Java/C++, so is it this?"
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
All I can say is "thank you".
Submit a comment