Getting Your First Unity Job: The Employment Triforce
I’ve put off writing this post for quite some time, and as such it’s made a cosy semi-detached home in my drafts folder, bought some furniture and picked out some lime green curtains, but now it’s time for it to fly the coop. The reason for this is that quite a few people now, including the cable repair guy (no not Jim Carrey) have asked me… “How do I become a Unity developer”, so it seemed pretty logical to regurgitate what I’ve said to them, arrange it in a post and share it with anyone that wants to be one.
As a mini-disclaimer, it’s almost impossible not to sound patronising when talking about this subject, so if I come across that way I really don’t mean to. I’ve been a full-time Unity developer for 3 years now and weirdly in Unity years (much like dog years, but longer) that means that I’ve been around. I’m not quite a “Tommy Lee Jones”-esque Unity veteran, but I’m getting on. And within these years I’ve been interviewed, interviewed others and done everything in between (nothing really in between). So to round off that point and to get off the subject of me, I feel like I have a few pearls of wisdom to share. Pearls that will not only strengthen your position with perspective employers, but hopefully land you your first Unity job.
I think there are really three parts of getting your first job.
I’m going to call it (for geeky gamer reasons) the Employment Triforce.
The knowledge, the credentials and the interview.
This is an obvious one, but I feel one that is overlooked, a lot. Whether it’s passing the typical technical test that’s given to perspective recruits, questions in the interview or just doing your job in general, you need to know what you’re doing. I’ve interviewed quite a few people, that when you ask them what they’ve worked on outside their survival horror first person shooter, they draw a blank. That’s not to say there isn’t any merit by sticking to one genre, but if two candidates come through the door and one has an array of small (even one day) projects including a first person shooter and the other one has just the first person shooter and their of the same quality, which one are you going to hire? Obviously, going into a entry level job requires entry level knowledge, but to increase your chances, the more bases you cover, the more chance you have of impressing.
Know the basics and know them well
As a bare minimum you have to know how to create a Unity game or app from scratch through to completion. Regardless if it’s a solo or team project starting and finishing a project of any scope and length is going to exposure you to all parts of the pipeline. Equally, working both solo and in a team is going to get you used to different environments. If you want to work in a studio (as opposed to contracting) having worked in a team already is going to put you in good stead. Unity-wise make sure things like: colliders, rigidbodies, awake / start / update vs fixed update, creating a UI, lights and camera setups, data collections and good code design are all second nature to you.
Know your platform
If you’ve just applied for that developer position and the company solely creates mobile games, then guess what, you should try building one. You don’t even need to do this from scratch, you can always port one of your existing projects over. Or if worse comes to worse create a quick one day project, just to say “Hey guys, I did this in a day, so it looks like balls, but I’ve played with all parts of the pipeline, I’ve decoded the ancient art of provisioning profiles and certificates and I know about the performance constraints and how to approach them”. This is only going to go down well! Sure if another candidate has produced a mobile game, and it’s better quality than yours, then they’ll have the edge, but you’ve already beaten all the other people that haven’t produced a mobile app and yes they do exist. Likewise, if the company is desktop only, then you don’t necessarily need to worry about things like draw call count and fillrate, but instead pump everything up to 11 and make something super shiny and pretty with shaders or flex your tool building muscles and create a useful editor script or toolset.
Have a diverse portfolio
Studios tend to take on client work to pay the bills and if not they’ll be constantly developing new IP, which could mean one day you’re working on a side scroller, the next a augmented reality product ad. Now obviously you’ve got a life: studies, places to go, people to see, so having a portfolio packed full of complete projects is a bit of an ask, but I can’t stress enough how far small one day / weekend projects can go in displaying you have a certain skill.
Want to show you can make that side scroller? Make a basic level and grab a sprite sheet off the internet, heck you could even just use a static stickman or blocks (a la “Thomas Was Alone”). Want to show you can do some AR product work, grab Vuforia get a free 3D model of a car, and create a turnable animation, with some nice lighting and if you want to wow, create your own metallic car paint shader. Just that project alone shows you know about AR, working with 3D assets, shaders, lighting and if it runs well (which it should) performance constraints.
Diversity displays a natural interest into learning new things, illustrates experience and makes you more valuable as a candidate.
Know programming practices
Either during the interview or the technical your prospective employer might graze lovingly into your eyes and ask “What is polymorphism?” or “Hey what’s all this draw call batching about?” and you may not always know the answer, which is fine (depending what it is) but by playing around in Unity, you’ll increase the amount you know, and decrease the chance of getting a question you don’t. Which strengthens my first point of being diverse in the projects you produce, as you’ll get exposed to more components and practices in Unity. If we use the example of the first person shooter again, this may mean you’ll nail the raycast question, but flunk the question on sprite animation or car physics. Also I can’t stress enough how important it is to follow good program practices, such as writing clean and concise code, encapsulating classes (adhering to OOP) and being performance concise. These things are not only going to make you popular on your team, but will also mean you don’t get booted out the window when it comes to the end of your probation period.
Learn 3rd party tools
Just like death and taxes, it’s guaranteed that you’ll be using 3rd party tools at some point and if you already know words like: NGUI, 2D Toolbox, Google Analytics, SVN / GIT / Perforce, Game Centre and million others you’re going to be in a better position than most. Think about this too, as the new kid on the block, you’re going to be given a set of tasks that don’t affect the core game (especially if the project is already underway) not because your new work mates don’t like you, but because they don’t think you’re the best person to tackle the main coding tasks (and they’re right, the lead or senior will be tackling those). So let’s think of some tasks that offer low risk (in case you make mistakes) and won’t cause any blockers to other developers, hmmmm… yes you’ve got it… “meta tasks”, such as: social tools, achievements, analytics and localisation tools. These things are typically easy to QA against and generally come later in the project, so they’ll act as your programming sandbox, enabling you to flex your programming muscles whilst causing minimum impact on the rest of the team. Now think how happy they’ll be when you come back a couple of days later, done and dusted, because you already knew how to do these kind of tasks right off the bat. Town: Awesome developers. Population: You!
Brucie Bonus: If you want to really push the boat out and have the time, why not create a small demo tailored to something that particular company do. Do they make sports games? Make a penalty shoot-out game. Make surgeon simulation games? Make a “Cauterize the Wounds” mini game (think Fruit Ninja, but much grosser).
What is the certification you speak of, I hear you say. Basically, putting your knowledge into some sort of easily digestible form (no not cake, it’s a lie) so that employers can easily see what you’re all about. I really break this down into two categories there’s the age old CV and the accompanying dev blog or portfolio. You should have both.
Now CVs are super subjective as different people like and dislike different types. I’ve perused very bland, very technically concise CVs, that make me think the developer knows his stuff, but I’ve also seen really cool artistic CVs (i.e. an interactive Unity CV) that make me think “Wow, this person is really creative”. I don’t think one is necessarily better than the other (people are probably dropping their monitors out the window at this point). I think it’s all relative to who you’re applying to and how well you’re presenting your skills in your given medium. Have a bland CV, but know C#, CG, 3rd party tools, strong maths and have a doctorate to boot, then no one will ever care that your CV is more boring than a monk in a sex shop. Have an interactive Unity CV, that runs at 5 fps and crashes? Then you may as well run that sex shop, as you’re not going to get the Unity job.
I think something that’s a given is that you really should have a development blog, not all employers will read it, but some will and it really impresses me when someone has documented their projects, their successes and their failings. It’s an easy way for an employer to see what you’re all about, and without it, it’s really down to whether they like that piece of paper for the few minutes they glance over it. Sometimes they might be having a bad day or they’re simply swamped with work, and your CV just sort of passes them by, at least with a blog they can get interested and engaged into what you like to develop and get to know a bit more about you.
This is the equivalent of doing the Indiana Jones slide under the closing stone wall and reaching for your hat, will you get it or won’t you. They’ve already liked you enough to want to see you face to face, and all you need to do is impress them enough to get them to want to see your face every day. That means if I got through this, anyone can!
Research the company
First thing’s first, make sure you know the company if they say “So do you know what we do here?”, that’s really code for “Tell us you’ve researched our company, and actually care about the job”. Subsequently, if they ask “So have you played our games / apps”, you better have because a “No, what do you make here again?” will result in a massive invisible “rejected” sign floating around your head, before you’ve said another word. So play their games as much as possible, research about the company, know what they’re doing both product wise and business wise (are they crowd funded / investor backed / expanding, a Google search should bring something up) this will help you both answer any questions they may throw at you and illustrate that you’re willing to take the initiative by finding out about them.
Confidences spreads confidence
Sounds like some stupid self-help line, but it’s true. Harder said than done, some people are more comfortable in interviews than others, but by being confident and tackling questions instead of just saying “I don’t know” constantly, is going to instil confidence in your prospective employer that you’re the one they want. If you stumble on a question you don’t know, be honest and say “I don’t honestly know, but I’d be happy to learn it”. As the junior developer they don’t expect you know everything, but they definitely want you willing and hungry to learn.
Also if you’re not confident talking, show it in another way. You could always create a playable demo for them to try out, print out some screenshots of the projects you’ve done with a few bullet points of how you made each one. You basically want to engage them, and whether that’s through talking confidently, or making something for them, that’s your goal. Make yourself memorable. However, just like the old Chinese proverb, keep a balance. Cockiness and confidence are two different things. Even if you are a Unity hotshot, they don’t need you, you need them, so showing a little professional courtesy (remember these guys and girls are going to be your co-workers) will go a long way.
Always ask questions
You’ll already know this one, but when you get to the end of interview and they ask “Do you have any questions for me?” that means “Now it’s your turn to show some interest and ask me a question”, so do so. Even if it’s something super generic like “What are you plans for game X?”, but really if you’re interested in the role, you should really be interested in the company itself and have a tailor made question for them. So for instance, if your prospective employer makes a basketball game maybe ask them: “Do you have any plans to create a game based on a different sport?” or “Do you have any plans about launching your game in Eastern Europe? Where Basketball is huge”. Showing a specific interest in their business and projects, not only shows you’re clued into what they’re doing (and therefore will fit in to the existing team) but that you actually want the job.
Fitting into the company’s environment usually comes in right at number 2 on the “most important requirements” list for a new recruit. They don’t want you to disturb the moral of the team and / or be a massive pain in the arse. So firstly, don’t be a pain in the arse and secondly, following the above guidelines, will show them that you’re ready to take the reins and you’re going to be a good person to work alongside.
Wrapping Up (it’s nearly Christmas)
Right hopefully that didn’t sound too “on my high horse”. Hopefully, these tips will help maximise your chance of landing that first job and if you’re an employer and have any tips of your own share them in the comments. I would love to hear them.
I really do feel that in terms of being a Unity developer these really are the golden years (when I first applied I only found 5 positions UK wide) and considering statistics like “50% of mobile games are being produced in Unity” there’s plenty of demand. So stop reading this, open Unity and go nuts 🙂
Shard = Job. Link = You.
- Comments (0)
Fatal error: Cannot assign by reference to overloaded object in /home/glitchgi/public_html/alexpoolton.com/devblog/wp-content/themes/mystique/atom-core.php on line 4232