I have a question for those of you who are full-time professional game developers that work for some company in the industry.

Let's say some person (me) with no professional game development experience is applying for a programming position in your company. Can you name something you'd expect to see in their portfolio of projects that would make you consider giving them a chance to interview? Would you expect to see full games or mods for existing games? Would you expect them to use an engine or write from scratch? Maybe non-games, more like demos showing that the author has mastered some advanced topic? Would you expect to see 3d games or would you be satisfied with 2d games with reasonably complex gameplay, given that the author provides some other proof that he actually understands the math behind 3d games?

P.S.: I'm working on expanding my current set of projects which include some 2d games written in c++ from scratch and I want to figure out what to do next, but I'm intimidated by 3d mainly because it's extremely challenging for me to create models/environments that don't look like complete crap (blender's UI made me curl up in a ball and cry). That is not to say that I don't understand 3d math though, I have some 3d "demos", but those are not games, just bits & bobs that focus on some particular aspect (e.g. lighting, or camera movement, etc.)

I'm a professional game developer who has worked on tiny projects at small studios all the way up to major AAA titles, and I've been involved with the hiring process multiple times, including being involved with creating an updated programmer test for a studio.

Keeping that in mind...

What I would want to see in a portfolio is finished projects. A small finished puzzle game looks better than a half finished FPS you made in some random engine. Personally I'm more impressed by projects that are written from scratch than using a large engine such as UDK or Unity3D (as it shows you've dealt with lower level things and put some real work in to it) but in general just having finished projects shows you have stuck through it and have worked through all the issues that come up along the way.

If a company is known to use a specific type of tech, having a finished project using that same tech will look very good. The same goes for mods; I've never been as impressed with mods unless they are extensive, but doing decent mods on tech the company is using should look decent in your portfolio as well.

Tech demos won't look as good as finished games, but as long as they are completed tech demos they can still look quite good.

2D vs 3D isn't going to matter near as much as you think (I'll explain why later). Both 2D and 3D have a lot of the same problems to solve, and seeing that you can solve basic gameplay issues and handle basic polish work (such as bug fixing) is what is most important to see. If you want to show off some 3D math skills or fancy shaders, tech demos can shine. I can't reiterate enough that you aren't expected to write a huge 3D game; small games and bits to show you can finish what you start and have an idea what is going on is the name of the game.

It's worth noting, unless you are trying to show off your art talent I do NOT care what your art assets look like. Grab something half decent from opengameart.org or turbosquid.com (among other places) or find an artist who is trying to show off their work. It doesn't need to be fancy and I'll instantly look past bad art assets to check out your code as long you try to show off your code... that being said, put a little effort in to finding decent assets as it'll help stick in people's mind better, and make everything feel more polished. It won't hurt you not having good art, but it will help a little if you do. The only time I'd really care about your art assets is if you were procedurally generating assets, and if you are procedurally generating decent 3D art assets I'd probably throw you straight in the interview pile regardless of anything else in your portfolio.

Something I never hear mentioned is version control. Learn how to properly and effectively use version control. Most of the game industry uses Perforce (which has a free version you can use at home), but experience with any big ones like git, mercurial, or svn will look greatly in your favor. If you've worked on open source projects where I can quickly open github/sourceforge/bitbucket/etc and see that you know how to work with others, merge changes, etc, you'd be looking far more valuable than most entry level programmers.

All of that being said, if you are an entry level programmer you are going to be applying for a junior programmer position doing mostly junk work no one else wants to do while you get experience in how things work. Have a couple simple finished games and a couple tech demos and/or OSS contributes to point at and you'll already be sticking your head above the crowd, everything else they'll figure out by giving you a programming test (one studio I worked at sent out the programmer tests before even looking at the portfolio).

Now i feel like im wasting my time mastering Unity (2 completed games so far). I should really start learning C++ now =/

EDIT: Nice feedback I got there!. Thank you everyone!. So yeah, I seriously need to learn C++, not just to learn it but to comprehend many things like the engine internals. Also, as the rumors suggest, UDK 4 is dropping Unreal Scripting to allow C++ Programming instead so, if I want to tackle UDK (and I do want) I should start by learning C++.

It is always a good idea to learn transferable skills instead of getting stuck in one sandbox. You could always tackle an irrlicht or ogre based project, that all gives you the low level grounding and you can even play around with the engine internals

That being said, Unity uses C#, which is a good transferable language as well. Though you may find programming in C++ difficult to return to.

They share many similar concepts (both being C-like languages), but end up quite different under the surface.

Unity also uses Shader language (an entirely different school of programming that I don't think many people consider).

Oh, and if you buy Unity Pro, you can even use C++ plugins if you want to. I haven't tried this myself.

I believe Unity has many transferable skills. What it does do, is skips you having to program a rendering engine, a physics engine, an art asset pipeline, a sound asset pipeline, an animation system, a particle system, a level design tool, and a component messenger system.

I don't know how many company's want people to be able to do the above. These types of programmers I generally find a game only has a few of in the credits. They are the uber-programmers, they get paid a lot, and they probably have very secure jobs. (Which means there probably are not a lot of openings)

After using C# for two years in a gamedev club, I have come to absolutely love C#! It isn't boring like Java, but it isn't monstrous like C++. (C is still my favorite language to mess around in, though)

Yep, I agree. C# is becoming what java was supposed to be thanks to the efforts of the mono project. And the language had got better with each new version released by Microsoft, which is surprisingly quick

In my eyes, the most important thing is making games, and finishing games. Knowing how all the pieces fit together at a high level, and knowing how development changes from building the game to polishing the game, are important skills. And nothing will help practice those skills in a real-world environment like a high-level engine.

Also, professional work will probably be done in something like Unity; games are way too big nowadays to not use some sort of toolset that's at least similar. Keep in mind that Unity is fairly easy to work with for non-programming disciplines, so most likely all content will go through some program like it. Unity also uses a component-driven engine, which has more or less become industry standard as far as I know.

But, you probably should learn C++. And probably C and some assembly if you can. And you should make at least a small game 'from scratch', which is to say, where you program in the update loop, make the draw calls, handle input, etc. You should do these things because there's important concepts to know, then go back to C#/javascript and pre-made engines because you don't need to reinvent the wheel every time you want to make a game. But, it's good for a doctor to know at least basic anatomy, even if he just performs routine checkups and doesn't need that information on a day-to-day basis.

I'm not sure Unity is WASTING your time. I've learned Unity because I wanted a job in Unity (and got one). As drakonite mentiones, finished stuff is important too. So it'll show your generic capabilty to solve specific game related problems. Learn another language only if it suits the direction you want to go. But don't ever feel like your time in Unity is a waste. As long as you're not doing repetitive work it's never, ever wasted time.

I wouldn't say that it's a waste. My overall point is that getting stuff done and showing that on a higher level overview you understand how to make a game and how to get things done is very important. Whether you do this in Unity, UDK, or write your own code from scratch with C++ directly to opengl isn't the issue.

That in mind, if you want to be a game programmer, you need to learn C++. I don't care if you're applying somewhere that exclusively uses Unity3D, UDK, or any other higher level engine; if you ever want to be anything beyond a junior you need to know C++ and you will be expected to know C++. Ideally you should learn and be comfortable with a few languages so that you reach the point you can quickly pick up any language you need to use.

As someone in his 3rd year of a CS degree with exactly 0 personal projects or code written, this is why I got out of it. This is completely true for any of my friends. You need pet projects to bolster your abilities.

A CS degree is pretty worthless when it comes to game programming. They don't teach you what you need to know and almost everyone who has worked in the game industry very long knows it.

What you have in your portfolio is infinitely more important. I can't speak for everywhere, but for places I've worked and most places I'm familiar with your CS degree will be largely ignored. I know of a couple places in which having a CS degree will help get past the HR departments prescreening phase, but they are rare and let's just say they aren't the type of places I'd want to work.

If it's something that you truly want to do, you should be teaching yourself and investing your time in to it. If you're motivated you'll be doing it in your spare time because it's what you want to spend your time doing, and it will show.

Forget about your resume for a moment; if you want to do game programming than take the initiative and teach yourself; do not wait for some class to learn. From all the people I've worked with, all the people I've interviewed, and all the people I've talked to, I've noticed a consistent pattern that those who took the initiative to teach themselves are better programmers and more successful than those who waited to learn in school. Off the top of my head, of all the programmers who passed the programming tests to get in to an interview, I can't think of a single self taught programmer that wasn't hired, while most of those with CS degrees were not hired as they generally didn't know what they were doing.

Ok, thank you for the reply. I appreciate it. I love game programming and spend a lot of my free time doing so. I was just afraid that I would have a hard time finding a job. I'll just continue doing what I'm doing then.

I didn't read that self-taught programmers are superior. At least that's not what I believe. The only thing I can do currently is to continue to work on my current projects, finish them and continue learning. I appreciate your response as well.

This can be a touchy subject, but I don't think his point was that self taught programmers are categorically anything other than sufficiently passionate to have learned what they're doing. The learning and the drive being the important bits, not the autodidactism. I suspect he only included his anecdote as reassurance that it is indeed possible to get a job if your degree is in something other than CS.

Senior devs would rather work on big new features than fix small bugs or visual issues. Which is handy, because Junior devs are a lot better suited to fixing small bugs and visual issues than they would be for designing entire new systems.

Other reply has most of it, though IMO there's a mentorship component that calling it junk work doesn't capture. Small stuff like little supporting tools, or bug fixes, or even babysitting build scripts -- these tend to be junior level tasks not just because they're smaller, but also because they offer the programmer a chance to learn how to deal with larger problems of that type later, and get rapid feedback on their efforts in the process.

Who cares if it looks like crap. Go and make something fun. If you don't like the graphics, then build a system that allows you to replace them later.

What I want to see is passion for what you do, and at least some skill in building working programs, including games. If you can put a game together, then I could spend the entire day talking to you about how you put it together. Even a trivial 2D platformer will get me all excited.

Building a game (even a very simple puzzle game) forces you to do many of the following:

Learn a language

Build a non-trivial program

Debugging

Non-trivial architecture

API/Library learning and experience (DirectX, OpenGL, SDL, etc.)

Game mechanics

All of those are valuable skills you will need when you start working in the industry, even if it isn't in games. You will also be applying for a junior position. Nobody is expecting you to be spectacular. You will learn. Oh boy will you learn. Your experience will increase and your contributions will become meatier. You (hopefully) will get a mentor that will help onboard you into the experience and be a guide for your questions. Nobody expects you to be steller. You should be plucky because everything will be daunting when you first see it.

Your hardest obstacle will be getting hired. Ironically, this will likely have little to do with your skill set. It will have more to do with how well you can explain yourself and whether or not they like you. That being said, YMMV.

It's not your demo reel that will get you the job it's your understanding of how code works that will. 99% of the time your portfoilo will get looked at but remember that I have no way of knowing if you did all that work or not so I am just going to test you to make sure that you can do the work. Do while having a portfoilo is important, but it's not going to get you a job.

Anyone can say they know how to program. Many people can even get through interviews! But NOTHING is as good a substitute for experience as finished projects that you can show off.

It's usually easy to tell if someone actually wrote code if you ask them about it. (Especially if you ask for source code, and ask them why they made the choices they did.)

On the other hand - I've known a terrifying number of new hires who could talk great through the programming theory in interviews, but were not great programmers.

Bottom line, the job is about programming games. So any games you can show that you've programmed will do a LOT more to tell the employer what you're like when you program games than an interview will. (Interviewing is sadly a very inexact science. :P)

Edit: Just wanted to respond to this point in particular:

99% of the time your portfolio will get looked

This is not true at all. Most places will absolutely look at your portfolio, because if you look even remotely promising (i. e. promising enough to interview) then they want to know as much about you as they can. Or at least, that's how it's been at the 3 game companies I've worked at so far.

Umm... how game companies usually hire game programmers is lots of interviews. It's you and some dude (maybe 1 guy every hour) in a room with a whiteboard for 6 hours. At the end of the day they aren't really interested in your demo when you are interviewing. Having a good portfolio will get you interviews and your resumes looked at but it's most likely not going to help when you are interviewing. This is for people that are just joining the industry.

That being said, during interviews they will ask you some past experience questions so having done projects will give you something to talk about. And yes, looking at your projects do give them a better idea of who you are but interviewing is still something that they do. It's not a perfect process but it's the best one they got.

I know all about the hiring process, and I've been on both sides of said interviews. :)

And again. It's not like your demos are going to get you out of the interview. But a good sampling of what you're capable of goes a HUGE way towards getting you an actual job.

Here's the thing: Companies hate risk. And bottom line, hiring someone is risky. (I think the usual stat is that if you hire the wrong person for a job, and fire them after 1 month, it costs your company around ~6-9 months worth of their salary, in wasted time for the team, and other people having to deal with their messes.)

So companies are ALWAYS looking for ways to reduce this risk. This is why interviews can be as long as they sometimes get. This is why everyone wants people with experience. This is why people want folks with college degrees. ANYTHING you can do to prove that you actually are as skilled as you say you are, anything you can do to help reassure the company that you are actually a hardworking, dedicated individual, is solid gold. Previous experience does that.

Having taken some personal projects through to completion does that. It shows them that yes, you can work, without supervision, and take responsibility for finishing something. It shows them that you have at least the level of technical competence demonstrated by whatever you wrote. And it absolutely WILL help you during interviews, since you can bring it up and say things like "oh yeah, I actually had to deal with a similar problem to this on [demo] - I tried way X first, but that turned out to be a problem because of [reasons], so I ended up having to rewrite it as Y." or whatever.

Bottom line, the single best thing I can think of to tell someone trying to get into the industry is FINISH A PERSONAL PROJECT. (Well, that and "network!")

That is why I stated that they will test you. Again like I stated before I can not know if you made the game that you are showing off in your portfolio. You are right some people do interview really well but in the end the only real way to know that you can do the job is to give you a test that is related to the job at hand.

That is all that I am stating. Again while your portfolio will get you looked at its the programming test and how you can talk about your code that will in the end get you the job. I was not nor did not say anywhere that your portfolio was not important, I was simply stating that its not as important as people think.

Seems like it would be hard to fake knowledge of linked lists, vector math, cs algorithms, best practices, etc. While an average programmer that is good at interview questions might be able to portray themselves as a great programmer in the right scenario, I find it hard to believe that someone with little to no experience could come off as an experienced developer. I do still agree that finished personal projects are a huge asset and one of the best things to have going into any programming interview.

You'd be surprised. Being a good programmer doesn't jut mean having a lot of knowledge of the subject; you also have to be able to apply that knowledge to problems you are completely unfamiliar with.

I've worked with many programmers who know programming paradigms like the back if their hand but unless the problem they are looking at fits exactly to a pre-existing solution, they are completely lost.

Sadly you can't necessarily assume that because someone has a lot of experience, they have learned from it all.

As Nortiest said, knowing the concepts isn't the same as being able to use them.

I've interviewed people who knew the concepts (by name!) well enough to get hired, but when it came to actually getting anything done, they failed utterly. They interview very well, but just don't produce.

And I've interviewed people who didn't know the name of anything, but if you give them a problem, they'll choose a good way immediately and get to work. These people interview horribly, but they're highly productive. (Just don't include them in meetings... That's back to the same skillset as interviews.)

What I really hate is having to pass on someone who might fit that second category, but having no way to tell. Without a portfolio, it's just really tough.

I find it hard to believe that someone with little to no experience could come off as an experienced developer.

You'd be surprised. :-\ It doesn't happen THAT often, but it does happen. It's usually not someone with no experience. It's usually someone with SOME experience, who is either trying to portray themselves as having more experience than they have, or portray themselves as having different experience than they have. ("Sure I know production-level ruby!")

I realize that, but before even thinking about getting the job, I have to do something that would get me "through the door", at least to a phone screening. You probably have piles of resumes to pick from.

I agree with Samsterdam's point. To get you in the door though, have some great work to show that you're proud of. Mods, projects, gamejam entries. Polished games are better then prototypes. With no experience it'll be raw tenacity and passion that will get you noticed from all the others. You need to prove you make games and not just some guy who wants to make games. It's even better if you can show you've pushed through the last 10% of game making (bug fixing, polish, QA).
When you're through the door - then it's quiz time.

Be careful with portfolio building. If your portfolio is the aspect getting looked at, you are likely to get questions about it. And they might be very detailed technical questions like, "I worked something similar in the past, how did you get around the problem of X."

Make sure that your portfolio only shows off things that you are comfortable discussing in intimate detail.

cultural match - you obviously must fit the dynamic of the group and company. show people that you're capable of working with them, taking instruction, and even giving instruction. be excited.

far and away most important technical trait - self-driven projects of significant size, preferably game related. school doesn't count. show that you're motivated and capable of solving difficult problems, because difficult problems occur in game development.

basic CS knowledge - know different data structures, when to use the appropriate one, and their respective efficiency (see: Big-O theoretical run time) for basic operations like adding, removing, and searching

The number one skill in programming is finishing things. I have known awesome programmers who just overcomplicated things until the project was totally bunged up; and I have known pretty poor programmers who just managed to churn out profitable product after profitable product.

So if you can show that you are an awesome programmer who can finish things then you are a superhero.

Also I have known people with pretty impressive 3D demos who got hired by games companies but then were put to work on things like the nightly build but not programming anything game related. So my guess is that they aren't looking for the guy who can get the framerate up by a factor of two but the guy who can zip their way through a huge list of bugs.

I'm a professional non-game developer, and I often review portfolios and sit in on interviews. I look for good code, mainly. Nothing tells me their ability better than their code.

If it's sloppy, I know they're a sloppy person. Spelling mistakes are annoying and a sign that maybe they don't care enough about the impact of their work on their coworkers. Security vulnerabilities are a huge mistake.

And if they pass that gauntlet, then I start looking to see if they know what code is impressive and what code is not. I start looking to see if they know how to make it readable and efficient at the same time, and which side of the line they're likely to end up on with really tough code. (Readability is the side you want to be on, BTW.)

And after all that, I'll look at the resume. I'm looking to see if they've collaborated with others before, and the level of work they've done in the past, both solo and in a team.

Buzzword Bingo is the last thing I look for on the resume, as I want to know they know about frameworks, source control, and other things that make coding more efficient and less stressful for everyone involved. Of course, I'm going to ask them about everything on their resume to see how well they actually know it.

If it's a single player game and not connected to any other computers, then security vulnerabilities only affect bragging rights. I wouldn't worry about them.

But it's getting to be the rare game that doesn't have any networked multiplayer support. And the ones that require account authentication are the ones to really worry about.

Looking at a resume, even knowing networking isn't part of the current project, I'd still be quite critical of security issues.

For single player stuff, more important would be things like Unicode support and anything else that affects accessibility/usability for the user.

And beyond all that, the interviewee should be able to tell me what assumptions their code makes, such as singleplayer-only or only accepting Latin characters. Knowing that their old cold has that limitation, even if they don't fix it, is definitely points in their favor.

Ah, all righty. But if someone doesn't have any networking professed (in resume or portfolio) and is a fresh graduate, is not knowing security in any detail besides "it's important" going to be a deal-breaker? I've never really done any networking, I just have some basic webdev experience so I kinda know about input sanitation so you don't get someone with a username "DROP TABLES * FROM ALL;" but not much beyond that.

Also, thank you for answering! I graduate this semester and although I haven't had any issues with interviews yet, I'd like to keep it that way as best as possible.

What is or isn't a deal-breaker depends completely on the company and the project they want you for. Interviewees (of all levels) need to either show they have the necessary knowledge, or that they have the ability to quickly acquire new knowledge. (The latter is actually more valuable. I've been asked to do something new almost every week for the last few months. I've never once said, "I don't know how to do that." Instead, I indicate that I'll need to do research into it as part of the project.)

Bad interviews are the best way to learn to do it right. Don't fear them. Of course, you should always do your best, but never walk away from one feeling like a failure. Improve yourself with the experience instead, and know that you're better for it.

And yes, I know that's hard advice to take. I was there once, and the only cure was to take more interviews. (Though I will admit that the internet has helped, too... I've found surprisingly good tips in random places like Lifehacker and Reddit.)

Not what you might be looking for but I recently got a job developing simulator software (not game-related) that includes working with 3D and C++ code.

Are you a Milton?
The interviewer was much more interested in whether I could function as a team member than whatever didgeridoo I had done in the past. If a team member is a bad fit with the rest of the group it can be more damaging to hire him than not. After it had been established that I was not a complete Milton (Office space, yay) I moved onto the next step..

Previousnessidy (Its now a word!)
What I had done in the past. I had a couple of things I had done, mostly school work but I had finished a relatively large software project (developing a safety system, not game related). After a brief chat on other stuff I had done I was deemed worthy and moved onto the next step...

Knowledgibility
They had me complete a test for them. Just writing a small program that incorporates most of what they are looking for in a employee. This tested various things such as my ability to work with algorithms and such. It was quite fun and after I had completed it I sent it over to them. A few days later I got hired.

So from my tiny experience I would say

Be a people person dammit!

Create a protfolio. It is much like a artists portfolio. You want to include your best stuff and only your best stuff. Crap will make you easily disqualified. Modify your portfolio according to who you are applying with. (I bet the guys creating FPS games would much rather see your FPS stuff than your mario-roguelike-strippoker clone). But be sure to include a link to more. You want to grab attention to yourself. Look shiny!

Know your stuff. All the people-person skills or previous mega-projects in the world will not help you if you dont have the actual know-how.

Completed projects are the best bet. If you are not applying for a very specific position, at least basic proficiency with everything that goes into the game code is a very big plus. And as people said earlier, you'll be thoroughly tested on the interview, don't expect your portfolio to speak for you.