The Engine Guy

Each game usually has two or three, these guys generally work on stuff like the visibility system, scene graph, the physics system, making sure the game actually runs in the memory footprint of the console, that it actually runs at the target frame rate, and that it doesn't take three minutes to load a level. If there's any assembly programming to be done, these are the guys to do it. They're also the ones to get all the crash bugs, and therefore the ones who usually have to work the hardest as the game comes to a close. (e.g. you'll be the one tracking down that elusive crash that occurs only when you spin around three times while standing on top of the third flag pole in the level while the moon is waxing (and of course it'll be the fault of the gameplay programmer who left 6 hours earlier!))

However, as with the graphics guy there are compensations. The feeling of joy you get when the game finally starts loading in under 5 seconds; when it's 1mb under the consoles memory footprint rather than 100mb over; when it's finally running at 60fps rather than a jerky 10fps. That feeling is unequalled, and it's definitely worth the slog it took to get there.

Engine programmers are usually fairly specialised to the area they work in. So for a demo I would suggest you focus on one area and do it well. (However if you want to submit a demo that does everything, feel free ;>) For example, it's okay to have wireframe boxes as a representation if you're submitting a kick-arse physics demo, however please do include some debug graphics we can toggle on and off so we can see all the cool stuff you're doing to make it fast and stable. Similarly if you're showing off a scene graph/visibility system make sure you include some debug we can experiment with, and that you include a scene which is large enough to stress your system. If you just include a world with three boxes in it which would have run just as fast without a visibility system on it then we're not going to be too impressed!

Mr. Everything Else

The last form technology programmers take is Mr. Everything Else. As a MEE you'll quite literally be working on hundreds of little tiny things no one else has time to do. For example you might be responsible for writing the code to manage the memory cards, or perhaps modifying systems to use a different loading method, or maybe writing code to generate high resolution screen shots for print. Like the engine guys you'll frequently be debugging crashes caused by other people, but you'll be jumping between the different systems rather than focusing on one area.

Is there a bright side to being a MEE? Sure, eventually you'll be moved off onto something else! Although seriously Mr. Everything Else is a fairly important part of the programming team and if working on one thing for a year sounds like torture for you, then you certainly won't get bored doing this. Plus the fact you're working on everything, means you'll know about everything, so when you do move onto doing something more substantial you'll have a good working knowledge of how everything fits together.

As for a demo, well usually folks who get hired in this position don't bring in one demo, they bring in 50, working across a range of different subjects, perhaps not all of them particularly well polished, perhaps not doing anything more than printing out a few lines of debug to show the algorithm they were playing around with works; but really showing a passion for working in games and an interest for working in lots of different areas.