In addition to the 'formal' interview where I try to get a grasp of the person and their capabilities, I alos offer a code test. Okay so does everybody - right? Here's how I do it: First, one of my favourite functions for the code test amounts to being atoh(), albeit specialized for the particualar application. 1) Part one consists of reviewing some code that was written inhouse which, in retrospect, could have been written better. I ask the person to take on the role of code reviewer. Their task, don't rewrite the code. REVIEW it. Add comments and ask about questionable constructs. 2) Part two is the fun part. And also the most revealing about the coding and thought patterns of the interviewee. In many cases this part is the deal breaker. I ask the candidate to write the inverse function to what they critiqued in part one. Essentially htoa(). In my specification for this 'inverse' function I practically tell them how they can achieve the results I want in about five-to-six lines of code. The catch? They get to take the assinment home! I tell them I want them to work on it in a stress free environment. No interview stress. No wacko "don't think outside the box, re-invent the box" questions. I want to see how they think and how they code. I ask for the results to be e-mailed to me with-in a day or two. The results I get are amazing. A solution can be written in about five lines of legible code. Over the years I have received solutions with more than 120 lines of spaghetti code that I have to read three or four times to see if the algorithm would even work. Convoluted, hard to read, difficult to understand, malfunctioning and in general random thought processes - OUT!