I have 3 games, each that can showcases all the features of the game in one minute.

Is there a key rule for how many games in a programmer portfolio?

Whenever I have reviewed applications or interviewed people, I am interested in exactly two things:

1) Will they do the job well?
2) Will they fit in? (That does not mean homogeneous, it means passionate. For me you need to demonstrate passion and excitement about SOMETHING during an interview or no hire.)

That is it.

Any code samples or demos you provide are evidence toward (or against) those two questions. You get to decide how much is enough.

For an experienced developer, it is enough to just provide a list of game credits. For an entry level job deciding what gets included,, if anything, is up to you.. Sometimes we interview and hire people who are young and enthusiastic graduates that list lots of useful academic projects but don't have any formal game portfolio. Sometimes we see game portfolios that provide evidence AGAINST hiring them. And sometimes we can look at a portfolio and decide we are going to hire them before we even interview them.

You get to decide what evidence to give to potential employers. There are no strict rules. Something that one employer loves another may hate.


It may help you to imagine yourself in the role of the employer. You have a project that needs more people. You have a long list of work to be done. You are looking for someone who can do those work items quickly and efficiently. You want someone who you can trust to do the job without constant supervision, and especially someone who won't force you to go back and re-work and debug their buggy code. Now imagine you have a stack of maybe 50 job applications, and you want to spend no more than 30 minutes going through the entire list. Most applications will get little more than quick read-through. Imagine you look at one application labeled 'Warnexus.' Now, in your thought experiment tell me what is on that sheet that convinces me to bother to look at your website, convinces me to interview you, or convinces me to hire you. Then do that.

Not really, different interviewers work different ways.


For example, I won't look at more than one or two projects before I decide on how much I like a candidate's code. So if you have lots of example code, make sure all of it is your best possible work. If you send me one example of really good code and one example of bad code, I will assume you will write bad code more often than good code. If you send me two examples of really good code, I'm more likely to follow up.

Remember that the interviewer is looking at a huge number of candidates, and will accept any excuse under the sun to reject someone. Respect the interviewer's time and don't throw a million things at them. Show your best work, even if that means a small demo instead of tons of code. Large code samples are harder to review and take more time, so they can actually hurt you if you overdo it.

Thanks for the advice!

I am going to choose a small game along with art asset and all the java files that make the game work. I don't want the work to go to waste. My game reads a source folder that contains 43 java files that makes the game work and contains art assets I created for the game.

File size is 1.16 mb so that should be good.

1. What do you mean by formal game portfolio? That is the first time I heard that term before.
2. By the way, am I at a disadvantage if I never work in a team before?

1. He just means "portfolio." Presumably, you have one that you include with your applications.
2. Yes.

1) Yes I do. =]

2) Looks like I need to work on that too. Thanks!

Artists need a portfolio. If you are making models or concept art or animations or whatever else, the employers need to be able to see your skills.

Programmers much less so. Some people have a web site showing off things they have done, many do not.

For entry level programmers most of the time we don't bother looking at their site. First we look at (and typically discard) their application very quickly. Most get 10-20 seconds. A few get a full minute. This brings the pile of 50 or 100 down to a pile of 10 or less. Web sites are not a consideration at this phase.

For those few that remain we might look at the web site on their application -- or we might not. Sometimes the site gets visited immediately. Sometimes the web site doesn't get looked at until after the interview is arranged, just a few minutes before we talk to the person. And sometimes the site never gets opened at all, unless the person asks us to review it during the interview.

It is extremely rare for an entry level candidate to have a must-visit web site. There are a few where the person built a crazy-fun game with mechanics and code that must be seen to be believed. I can immediately recall two games in this decade. One built a very fun networked RTS tank game. Another built a bizarre but fun game dropping cows with machine guns out of airplanes. In both cases most of us had decided to hire the individual based on their hobby projects alone.

Almost always at the entry level I find web site portfolios feature so-so senior projects and tech demos that demonstrate little more than the fact that the student learned to program and that they have an interest in making games. Sometimes they instead demonstrate that the student did not learn to program, and that is what I look for in portfolios.

For programmers you can build a fancy web site portfolio if you want to. Just know that if your application and resume are not very strong the web page will not be visited, and more often than not the sites will indirectly provide evidence against your abilities rather than for your abilities. Most entry level programmers think their terrain engine or side scroller is the best code in the universe and should land them a six-figure paycheck fresh out of school. But it isn't. It is entry level quality, generally not professional quality work.

EDIT: Adding a story:

A student welder just completed his project. After many hours of tedious work, he shows off forty perfectly welded steel joints. This is the student's best work and he wants to show it off. The other students admire the work, calling it amazing and wonderful.

The student brings it over to a professional to ask their opinion. The professional looks it over, calls it 'adequate', then returns to the project where he has already made over two hundred perfectly welded joints that morning before lunch.

Student projects are exactly that, student projects. Many times it is like the ten year old hanging their masterpiece artwork on the fridge. It is very rare for an entry level student work to compare favorably with the work of professionals in the trade.

I will use your stories as leverage in improving my portfolio and resume and cover letter. Great info!