Hello all, I know this could be too broad but I''ll try to narrow it down. I just recently graduated from college and have lots of time on my hands to continue from where I left off in my OpenGL game programming course. During this time I hope to hunt for a job like many of you and maybe even work along side those in the field. But when it comes down to the interview and getting that job I was wondering what kind of things shine through? Just by typing this out I think came up with the answer to my question of "what do game developers look for" and that is, a FINISHED game under your belt. Luckily I''m working on that as I type this and I''m hard at work with 2 friends trying to finish a small strategy type of game in OpenGL. So I guess my question changes to "is there anything else I should focus on?" Do interviewers look at small things you''ve made? like small demos of bouncing balls, demos of a guy shooting things and object reacting and colliding, etc... These things wouldn''t be games, but just a demonstration of your code. Are these things looked at at all or would I be wasting my time in trying to come up with these smaller things? Do most interviewers look at what''s on your resume and ask what games you''ve completed and that''s it? On the other hand, are there anything all interviewers would expect every game programmer to know such as knowledge of data structures and object oriented programming? Just trying to get an idea of how the whole programming interview process goes. I''d like to make sure I make a good first impression and present myself as though I''ve done some research on how to go about applying. Thanks for reading this far! Nexpert

Some personal feedback. I am on my 2nd industry job, and my first I was hired right out of college, so this may be relevant to you.

Background info:

Graduaged May 2000, with a CSE degree.

Fairly good GPA (3.2ish)

One of my senior projects was the design of an economic strategy game (it was implemented, but wasn''t really ''fun''. The design doc was very thorough, however (along with our reports on what we learned and code printouts, it was about an inch thick.)

For a long time (before I really got hardcore into programming, I was one of the people here who would ask stupid questions rather than try for myself or put forth effort first.

I found my improvement in programming and knowledge inreased exponentially when I stopped posting questions here all the time and just stuck my nose to the grindstone.

I got into programming very late in college (in fact, was an electrical engineering student for about 3 of the 4 years).

But, that should go to show that if you put effort in, you can quickly learn _a_lot_. But, you have to put the effort in.

My senior year of college, I was programming about 14 hours a day, all year. I took 6 programming classes.

My first job was at Outrage Entertainment in Michigan, my second and current job is at Ensemble Studios in Dallas.



Things I know factored into my getting a job out of college:
+ They liked that I graduated in a relevant field. (CSE)
+ They liked that I had a burning desire to make games, and had pursued projects in the area.
+ They liked our design doc for our game.
+ I scored well on the programming test they had me take (not all companies make you take tests, but they all more or less will want to verify you have some technical ability. This is much easier if you have shipped a commercial game.)

Things I know factored into some of my coworkers there getting hired out of college:
+ They also had demo games (some were very good, much better than mine)
+ Some of them had interned at game companies (Maxis, etc)

I don''t hire people, but from what I know having talked to my tech directors at both jobs, they don''t want to see 10 demos of bouncing balls. They want to see your resume, work history (relevant), and one good demo in lieu of experience. One good demo being a complete game, or sophisticated demo of some subset of a game (physics, AI, etc)

You could do demos of physics stuff if you are interested in that, or AI, its sort of personal to what you are good at, just make sure its very polished.

I think more or less interviewers expect you to:
- Have good knowledge of programming (typically C++).
- Good problem solving skills.
- You get along with them.
- They need what you have to offer.

As far as the programming interview process. Here''s a really good read about the interview process at Ensemble Studios works for programmers. I went through it this summer so even though the article is older, its still valid.

http://www.ensemblestudios.com/age/studioscandidates.html

No, I moved down here right as the expansion was shipped more or less.

I''ve been looking at the industry for a while now. I feel most enlightned by reading the job boards <Gamasutra is probably the best>. This lets me see what various employeers are looking for in a canidate.

Many want to see a shipped product or Demo. Some want to see code samples, other want you to take a "test". Best advice is....see for yourself.

-VenDrake

quote:Original post by LordDeath
For a long time (before I really got hardcore into programming, I was one of the people here who would ask stupid questions rather than try for myself or put forth effort first.

I found my improvement in programming and knowledge inreased exponentially when I stopped posting questions here all the time and just stuck my nose to the grindstone.

This *IS* very true. I can''t say how well it works later in life, when you''ve got work, and things in the way. I started at 10. I grew up in the C64 era. We didn''t have message boards on the web. You were lucky if you knew another programmer at all. You had a book or two, an assembler (or monitor... basically asm without labels, compiled as your type it), a sprite editor, a character set editor, and a lot of free time. Sometimes an interesting trick was published in Compute! magazine, and you''d pick that up. Add in your brain, and those were your tools.

For the most part though, it was learning how to string together more and more instructions to do more and more complex tasks. Every now and then you''d get moment when some new technique, coding style, or whatever, would suddenly make sense. If something didn''t work you tried to figure out why. You didn''t have single stepping, or output windows. You found ways to track down the bugs though. Today''s programmers have debugging much, much, much easier. Often you''d change the border color, or put a single character on screen to mark progress. When your code crashed, you''d look at the screen and have a vague idea of where it crashed... you''d turn the power off (or hit reset if you had a C128), load up the app again, and stare at it.

When put all together, the most importantly thing is you knew what everything was doing, why it was there, and learned how to use it... and it didn''t really take that long. With the tools available today, working out the hows and whys of each bug yourself are much easier... and it''s rewarding. And you''re learning to be a better programmer.