[Written for my newsletter, but of general interest.]
DOING THE JOB IN THE INTERVIEW
When you interview someone for a job -- any job -- it is, at best, hard to tell if they are truly going to do well at the job, or whether they just talk a good game. Many employers have taken to administering various sorts of tests to try to determine whether interviewees can perform the job adequately, without having the interviewees actually perform the job. Why not have them "do the job in the interview?"
That's the thesis of Nick Corcodilo's book, _Ask The Headhunter: Reinventing the Interview to Win the Job_. In his book, Corcodilos details not only how to win the job by doing the job in the interview, but how this produces a better fit between employer and employee. This makes more sense than the current situation, which more resembles the tale of the blind men and the elephant than a serious effort to determlne whether an interviewee can do the job. Having interviewees do the job in the interview will separate the fakers from the folks you want to hire.
What is the object, anyway? It is to hire someone that can do the job. Interviews are a means to that end, not an end in themselves. (The conventional interview may be an example of H. L. Mencken's dictum that for every problem there is a solution that is simple, neat, and wrong.) "Doing the job in the interview" may not be as simple as the standard interview, but it is simple enough for anyone to use, neat, and the right way to distinguish which interviewees will make the best employees.
So how do you have the interviewee "do the job in the interview", short of converting the interview into a lengthy, unpaid apprenticeship? Although the proof of the pudding is in the eating, you can get a pretty good taste in the space of an interview. Here are some techniques for "doing the job in the interview" to quickly determine whether you have a poseur or a prospective employee on your hands.
Tests during an interview range from the sublime to the ridiculous. The ridiculous might be worth another newsletter by itself, but let's concentrate on the sublime for now. When I have interviewed people in the past, the position has required enough low-level programming work that a simple test -- asking the interviewee to write code to convert a byte to the equivalent string of ASCII 1s and 0s -- is very effective. Not only does it show how well the testee understands close-to-the-silicon programming, it reveals how well the testee can think problems through. For that is the crucial point -- how quickly can you demonstrate how well the interviewee can do the job.
The test above is good, if the position involves some close-to-the-silicon programming. Other areas of expertise will require different tests than the test above. The acid test for an interview test is how well it measures the candidate's ability to do the job. The closer the test comes to "doing the job in the interview", the better guide it is for the interviewer. You can surmise from this statement that aptitude tests are not what you need, as aptitude tests are at best once removed from what is needed to do the job -- and other tests like stress tests, personality tests, etc. are even further removed from "doing the job in the interview".
If the work is not mainly covered by non-disclosure agreements of some sort (whether commercial NDAs or military classification), then having the interviewee sit in on an ordinary meeting can tell you a lot about their abilities, IF they are the kind of person who will, unprompted, speak up at meetings. Positions where one can be a shrinking violet but still be perfectly competent at the job are not good candidates for using this technique, as you will lose too many good candidates to the vagaries of the human disposition. Conversely, jobs that require much coordination and communication will definitely benefit from testing interviewees by having them participate in a meeting.
Sample work is good to review as part of the interviewing process when the role has a tangible output. Administrative, sales, etc. positions will find it hard to use the review of sample work in the interviewing process, because there is little that can be saved to a portfolio in those positions. Software engineering -- particularly the programming end -- can result in assembling quite a portfolio. Open Source helps this process along for software engineers, as it can provide a ready source of code for review by outside parties. Perl code excels at this, as the executable is also the source code.
SMALL TASKS FOR FREE
Small tasks done for free are a variation of sample work with the added advantage that the work directly relates to the position. The major disadvantage is that, unless you are applying for an unpaid volunteer position, doing the employer's work for free could set a bad precedent in the employer/employee relationship. The major advantage, from the prospective employee's viewpoint, is that small tasks done for free demonstrate that you are eager to work for that company. From what I understand, you will see this technique used mostly where there are a very large number of applicants for a very small number of positions, such as in the front-line positions (DJs, actresses, etc.) in the entertainment industries.
Like any tool, "doing the job in the interview" can be misused. As an employer, you need to ensure that you don't give away too much valuable information during the interview. As an employee, you need to ensure that the interviewing company is not going to use your ideas without hiring you.
If possible, using a sample task to be performed in the interview could be the safest course for both employers and employees. Employers need to watch for this too, as you will want to hire the best people you can afford -- a reputation as "the company who lives off of interviewee's ideas" is not the reputation you want to have when trying to recruit the best and the brightest.
The goal is not to interview people -- the goal is to hire someone who can do the job. "Doing the job in the interview" can be a powerful tool towards this goal. Although different jobs will require different methods of "doing the job in the interview", the closer you get to "doing the job in the interview", the closer you get to finding out whether the interviewee can do the job -- which is a win-win situation for both of you.