A lot of current programming applicants are graduates of "Computer Games Technology" or similar courses. While these courses teach more specifically games related content than a Computer Science degree, the portfolio of work is still not often suitable as a demo. Lots of the demos we receive are simply a collection of 3 years worth of assignments, and don't look good compared with one really polished demo, especially if the work was unfinished.

Whatever the position applied for, a single polished demo is always going to be a better showcase than spreading the time available over a number of lesser projects.

A tools programmer needs:

• Fluent C++ - not just C compiled by MSVC, but templates, stl, OO patterns...
• A good understanding of vectors and matrices.
• Interest in the technical side of game development.

Useful skills:

• Experience with Maya and XSI primarily (But Max, MotionBuilder, ZBrush etc all useful)
• Experience in scripting languages (Most 3D tools have either their own script language or a more standard implementation. MEL, Maxscript, JavaScript, VBScript, LUA...)
• Experience with GUI programming.
• MFC or Win32 are common but becoming outdated
• .Net Windows Forms and C#
• Java Swing / QT under other OSs

For a demo, anything which demonstrates some of the above skills is good. So it could be a game, or a windows app, or possibly a particularly interesting Maya plugin. Regardless of what the demo is make sure source code is included.

If its a game, make sure its technically proficient, an amazing new gameplay innovation is not needed, but keep it well presented, possibly with a nice UI. Shiny graphics and complicated shaders are nice but not necessary. Of more interest will be the data structures for the engine such as BSP trees, KD trees etc, collision routines, well designed systems and clearly written and commented code. Tetris probably won't cut it.

A windows app could be a model viewer, a raytracer, a normal mapper etc. In this case make sure the UI is simple, attractive and easy to use. If its a 3D view make sure there is simple object picking, framing and camera motion. Again the internals of tools are important, so a well abstracted file loader would be of interest in a model viewer, able to load multiple file types through a common interface. A raytracer could support multiple hierachy structures, for comparing the performance of different tree types for example.

A plugin could be literally anything, but should again be well designed both from a UI point of view as well as the underlying code.