• Game Programming Tests

• 
  Programmer tests are generally one of the most loathed parts of the interview process, on both sides. But every game programmer interview should include some kind of test to make sure the applicant can walk the walk as well as talk the talk.
  There are a few types of tests a programming applicant can expect to see. The first is a pre-interview test, which may be given by email and may either come before or in conjunction with a phone interview or screening. The second is an in-house test, which is given as part of the face-to-face interview and is completed on the spot. The last type is a take-home test that's given after the interview, which asks the candidate to complete longer assignments that are usually very closely connected to the day-to-day work the applicant can expect to see when employed, although these are more generally given to content creators (creating a level and so on) than to programmers.
  How these tests are handled matters immensely, both for the candidate being grilled and the panel of smug arms-folded engineers doing the grilling. Are the interviewers asking the right questions to get the answers they need to make a good judgment call? Or are they just trotting out their favorite trick questions so they can feel vaguely clever that they know the answers and the applicant doesn't?
  Now from the point of view of the technical testing, this engineer is firmly of the opinion that pre-testing is the way to test basic programming competence.
  With most job applicants, the interviewers have only one day in which to base a judgment call that can impact the applicant's life. Changing jobs can often mean moving, packing up family and so on -- and for the interviewers too, since they'll be working with the new hire day in and day out for possibly years.
  Sticking an applicant in a room to complete a technical written test, letting her chew her pencil and desperately try to remember what C++ operators can't be overloaded, is probably not the best use of that small amount of time.
  Technical tests need to be like filters. They need to help the hiring company figure out which applicants they should spend their time and money on bringing in house.
  Be aware though, that this process is negative filtering. Someone who does well on a technical test isn't necessarily a good programmer and won't necessarily fit with the group, but someone who does poorly definitely won't be a good programmer. The idea is to find out whether that someone at least sounds technically competent before they set foot in the studio. At that point, the hiring company is making a few assumptions about the person and can safely move along to other things when the interviewee shows up.
  What is a Written Technical Test?The first thing is to understand the purpose of a written technical test. Its purpose is to
  
  1. test domain knowledge
  2. test general programming acumen and
  3. give the interviewers an idea of the candidate's experience.
  It's not designed to reveal how applicants think, uncover their deep knowledge of STL edge case implementations, or see how they react to logic problems.