I was wondering, if by chance, anyone here might have some advice for someone that is not in the typical recent college graduate situation. I recently graduated from Eastern Washington University with a BS in Computer Science in March of this year. Due to family needs, I wasn't able to find any programming or computer internships that helped make enough for bills and family needs until last December. So, for six month's I was finally able to generate real world code as a job and loved it. The twist is when June hit, I was activated to deploy to Afghanistan, and the summer I spent training up for my current mission. I am now currently in Afghanistan with the laptop that I did most of my school programming on with the environments I used still set up, but I am banging my head on the keyboard trying to figure out what would be the best use of my limited spare time to continue growing my skills, trying to minimize the amount of skill degradation (use it or lose it), and trying to become marketable when I return to the states next fall. I noticed the hiccup in most Software Developer job posts for entry level usually go along the lines of a four-year degree plus three years industry experience. That's why I believe I really need to keep growing even in such a very odd location. I would really love to get into games, but any programming assignment would at least be a step in the right direction to achieve my dreams.

As I know there are many individuals out here in multiple computer industries and with as many different backgrounds, any advice you all have would be greatly appreciated.

Thanks.

Work on creating a portfolio of demos to show prospective employers. These projects should have a few key traits in common:

1. Keep them relatively small. Don't expect interviewers to spend more than a few minutes looking at them, unless they are truly wowzer demonstrations.
2. Each demo should be a focused demonstration. A graphics demo doesn't need great sound or AI (or really any, for that matter). A content management demo doesn't actually need great content (typically just a lot of content, hopefully to show off how well it's all managed). A multi-threaded demo should only be complicated enough to provide the possibility of race conditions, dead-locks, etc to show successful synchronization and concurrency.
3. The portfolio should contain a single, concise document that lists each demo with a short overview of what the project is and what it's meant to demonstrate. All other documentation should just be the source code.
4. Spend the time to make sure the source code is polished. This is your sales pitch to the company. Make it a good one.

Outside your portfolio, for your own usage, create a list of talking points for your portfolio. Two talking points you should have for each demo are:

What was your biggest hurdle/challenge in creating that demo?

What was your biggest sense of accomplishment from creating that demo?

Other potential talking points (be sure to think about potential talking points WHILE you work on the demos):

Other methods of implementation you thought about when developing a given demo, and why you chose the one you did.

Any funny or oh duh! moments when working on a given demo. Just be careful not to talk about anything that may make you look incompetent, but everybody makes mistakes, and sometimes those mistakes are funny. Other developers can appreciate the humor and being able to acknowledge that you make mistakes is an important part of meshing well with a team.

Keep the portfolio as small and as easy to distribute as possible. That means minimal media. Simple graphics and audio. You're after a Software Development job, not a graphics artist or musician job. The portfolio should be easily distributable by email, so no more than a few megabytes at the most.

And don't provide demos of stuff you aren't absolutely comfortable discussing. You'll only ruin your credibility if you provide a demo of some advanced graphics technique and during the interview you completely fumble any discussion about that demo, and the pressures of interviewing can sometimes turn less than solid understanding of a concept into a blank stare.