What do potential employers look for in a good portfolio?

Question

A buddy from work and myself are wanting to get into the indie scene for game development. I've done a few tech demos demonstrating different ideas and approaches for various problems. Now, I feel it's time for us to commit to a project in order to develop a portfolio for later down the road.

I've been struggling greatly with how to begin an actual project, more specifically to create an engine or use an OTS package, or use one then create one, or create one then use one.. etc.

Which looks better to potential employers? A smaller portfolio of games that includes your engine or a (possibly) larger one that was built using something OTS?

I am a programmer. I'm not an artist. I will be performing most of the programming for this project. My buddy is also a developer, but he is also proficient with graphical tools (thus, he becomes the art guy).

At work, we are both .NET developers (C#). I know, I know "Well then use XNA" some will yell at me. The demos I've completed thus far have been in XNA. But I have some concerns with building an XNA portfolio. While it is nice to abstract DirectX, I worry that I may not build the necessary knowledge base to extend beyond XNA easily. The counter to that argument is probably "you can more easily move on to DirectX after XNA", but since I will move careers from Business Development to Game Development, is it even worth while to focus on XNA currently? Or will potential employers giggle when I say XNA?

Should I embrace the experience of XNA knowing the concepts and lessons learned will mostly transfer? Or spend my most valuable resource (time) else where?

Looking for some advice from any industry vets out there.

Answer 1

I've been a programmer in the console game industry for almost fourteen years, and have often been involved in hiring decisions.

So speaking as one of those potential employers, when evaluating a possible employee there are three things I look for in a new hire, and I look for them in this order.

1. Will this person fit into my team? (social, hygiene, etc)
2. Is this person a quick learner? (often incorrectly phrased as "is this person smart?")
3. Does this person have any relevant experience that will help me?

Now, addressing your question. This whole "which type of project should I do" issue is addressing by far the least important of the criteria that I care about. I care far more about whether you'll fit into my team socially, and about how well you'll be able to learn new things quickly, than I care about whether you used XNA or your own game engine in some previous project. By and large, I'm assuming that I'm going to have to train you up in our own in-house game engine, and so your earlier projects don't really matter to me at all. That is, of course, unless you magically happen to have experience with a particular tool or technology that I need someone to know about. But this is unusual; usually, I'm assuming that I'm going to have to train you up to use our API.

All of this isn't to say that I don't want you to have done home projects. I absolutely do. But I don't really care about what those projects are, or what technologies they used, because they probably aren't going to be relevant to what I need you to do for me, since we'll be using different libraries or APIs.

But I do want you to tell me about your projects. I want to see how enthusiastic you get when you talk about them, because that tells me about what sort of person you are (see point 1, above). I want to hear about the problems you ran into, and how you overcame them in developing your project (see point 2, above). I absolutely want you to have completed at least one project -- being able to push through the pain and actually complete something says a lot about the sort of person you are, and tells me that you're somebody I'll be able to rely on if ("when") things get tough.

So honestly, neither option is "better"; the important thing is to complete something, anything. Any technology you learn along the way is icing on the cake, but almost certainly isn't what would make me hire you.

(But with all that said.. I will expect you to be proficient in C++. One way or another, you really need to learn C++ in order to get hired into the mainstream games industry. Your home projects don't necessarily need to be in C++, but I'll expect you to be able to demonstrate fluency in it.)

Answer 2

One thing others haven't mentioned yet is that it's important to finish your projects.

Having a portfolio with a bunch of unfinished things isn't nearly as impressive as a portfolio with one finished, well-polished thing.

Also, if you base your work on someone elses' existing work (such as some open source engine, or freely available art assets), make sure you mention on your portfolio which part is yours.

Answer 3

It seems to me that the answer depends on what kind of game programming you want to do.

If your goal is to be an engine coder or graphics coder, you'd benefit from going under the hood and learning how engines work. This doesn't mean you can't use XNA or another off-the-shelf engine, framework, etc. Gaining familiarity with the innards of a high-quality engine is a great way to learn how to build a high-quality engine! If you go this path, you don't necessarily even need to write any actual games. A portfolio of standalone graphics demos and/or nontrivial extensions to an existing engine (e.g. implementing a new shader in an engine or suchlike) will do you well. You can take a look at my portfolio of graphics demos here; it's a few years out of date now, but this is basically what got me a graphics programming job at a game studio.

On the other hand, if you'd rather be a gameplay coder, one of the people who work on the game mechanics, controls, enemy AI, etc. then your time won't be well-spent digging into Direct3D. Of course it's helpful to have a general, high-level understanding of how graphics works, but in a professional context you probably won't be coming into direct contact with low-level graphics stuff very often. In this case I would absolutely recommend using an off-the-shelf engine so that you can spend your time building actual games.

So, to sum up, if you want to do gameplay then just use an existing engine; if you want to do engine/graphics then build your own stuff and/or extend an existing engine.

Answer 4

when i was just finishing uni my portfolio was featured in this article. it does seem a good idea on what to do and what not to do when getting your portfolio together

http://leewinder.co.uk/blog/?p=23

Answer 5

Don't do your portfolio based on how you perceive the "standard" to be. You should work on projects that interest you. If you like game mechanics, go ahead and make a bunch of games. If you like creating interesting AI, maybe make a demo for an RTS-like setup. As an example, I have a growing interest in graphics programming, and putting more time into learning rendering concepts and applying them in my engine. (Consequentially, my game project has been temporarily put on the shelf.)

When you work mostly on things you like, it really brings out the "you" in the portfolio. On the other hand, having at least one completed game shows that you can pull through the "uninteresting" parts of making a game. It's good to have some degree of flexibility to break into less familiar territory, but don't force yourself into it extensively. You can tell good portfolios from the level of enthusiasm and interest put into the work, and projects based on your areas of interest are naturally gonna get the most polish. So whatever your area of interest is in, you will eventually have to focus towards that area of programming for a job.