02-02-2004, 08:49 PM
Originally posted by Boone
Lets talk about the CG-Programmer's "Demo-reel / Portfolio", the dos & don'ts...
A portfolio for a (CG) programmer is a lot harder to construct because there is often nothing visual to show and even the visual results of prior work mostly also does not indicate anything about the experience and skill level of a programmer in this particular field. Similarly, programmers often can't show any of their previous work due to agreements with their former employers (who will not like programmers showing around proprietary tools). Because of all these things that make it nearly impossible to cultivate a portfolio in a way that artists do there are other ways to assess potential new employees. Interviews being the most important aspect.
When we hire new programmers/engineers the process is usually an interview based on a pre-selection of their resume. That process itself can be quite a challenge because programmers can misrepresent things more easily (accidentally or intentionally) than an artist. It's way too easy to claim 10 years of experience in writing OpenGL or Inventor based apps only to discover the actual quality of the skills and experience isn't what one would expect of it. Based on the pre-selection the interview process is the most valuable and I have found that it really works out best to spend a good few hours with a single candidate, preferably in a social and casual environment after a more brief stay at the office to get a bit of a 'taste' of what goes on. While I can get a good general impression of someone's skills and experience by just talking to them I always tend to get one or two more people involved in the process. Discussions on technical aspects, teamwork aspects, prior experience and skills, etc. tend to shake out pretty well after a few hours. The casual environment and location of choice also tends to help in assessing someone's enthusiasm and interaction/personal/communication skills.
I've heard of some places giving people a test or two (like a written test) but I don't believe those are of any practical value. So what it always comes down to in most situations is communication. The best part is that during the lengthy but casual interview process, if there is any indication that the skills or experience of an individual are exaggerated or don't quite match up, we get to fire off a number of trick questions. Anyone trying to b*llshit their way through an interview tends to expose themselves as such quite easily. So as far as do's and don'ts go, do not ever talk along on subjects that you really feel you don't quite grasp or deal with because it'll make you look bad (especially since nobody will let on that you just fell into a trap). :)
Being able to show some prior work, tools, code, anything is always great but as with any hiring process you really can never be entirely sure they were created by the individual itself so nothing short of a good interview will be the determining factor. Showing any prior work is always more complex because while you can send out a portfolio of images, still or moving, is one thing, sending out applications and sample work is another. Bring your laptop, show some stuff, but generally don't count on those elements to count for too much because it'll always come down to communication in the end.
Another important aspect is the kind of development job in particular. For anyone who has to work as part of a team I really focus on communication skills over anything else while for someone on a more specialized R&D 'island' I will overlook part of that in favor of someone's 'compusqueeb' skills (e.g, it's ok to be a complete geek who lacks social skills if your job revolves mainly around things of a single-point technical nature). One of the things I tend to give a bit of weight is when a candidate, while discussing some of the stuff we do and expect the person to be involved in, comes up with a remark or two that makes me think "gee, why didn't we think about that". So do try and be innovative and try to point out a flaw or issue you feel strongly about could be done better or you think you've got an idea about that might help or work out better (as opposed to not trying to make the potential employer feel like an idiot and agreeing with everything that's said).
It rather depends on what area of CG programming you're talking about. I can't really speak about games (its a few years since i had anything to do with it, in those days it was pretty much either via a degree and/or showing that you'd written relevant code in the past).
In vfx there seem to be three main ways of getting 'in'. Most programmers seem to come in either via the games route (which tends to prove you a: understand 3D, and b: have worked with other people, c: know what deadlines are).
Some come from an academic background in CG. So if you've done a Ph.D. in a related portion of CG then you tend to attract the attention of vfx R&D groups.
The final most-common way in is by being a trained computer scientist (usually to degree level), who then becomes a TD. That way you know the basis of CG, and also get hands on experience of using it in production. After a few years you can probably choose whether you'd prefer to shift to a more coding-oriented job.
Having said all that there are as many routes in as there are people doing it. Some of the best CG programmers i've met seem to come from the most bizarre backgrounds.
01-17-2006, 07:00 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.