Slashdot Mirror
Written Tests for Interviews?
University Tech asks: "I am a technician
at a small private university in the process of hiring a new technician. Everything here is done by committee. One of the committee members was very offended that we were giving the interviewees a written test after we had finished the oral part of the interview.
How many of you have had written tests as part of a job interview? I think I have had one at every tech job interview I have ever had (six interviews) and even two hands on tests. Most of my co-workers and friends have as well. Is this perhaps a regional thing or is this normal for us techies?"
Having a written test seems like a good idea, though, since:
you can show the written test to someone else who is involved in decision making, but did not attend interview,
you lower the chance of an applicant claiming later that they weren't hired because of some prejudice,
it gives people understanding that they are tested not on how they dress, but what they know.
In fact, if you are hiring a developer for example and the candidate does not have anything conrete which he has done to show to you. If the candidate is asked to program for example 3 simple (and quick) programs related to his/her future work - then both the future employy and employer have much better basis to form their opinion on. Based on my experience, people on LIKE to do these real-life tests, because it makes sense. Why would you want to start a job that you will be uncapable of doing?
I'm not a laywer, but luckily, some lawyers write web pages.
According to "Pre-Employment Testing of Applicants", written tests can be dangerous because "A multiple choice aptitude test may discriminate against minority applicants or female applicants because it really reflects test-taking ability rather than actual job skills."
Now there's the old thorny issue: If you give a test of type A and group P has a high tendancy to do badly on a test of type A, are you discriminating against group P?
You like splinters in your crotch? -Jon Caldara
Personally, I feel they are ridiculous. Inevitably, you end up getting asked things like:
In SunOS 2.x, what was the command used to check how much belly lint has migrated into your power supply?
What is wrong with this piece of code? (inevitably written in your least favorite language)
In Perl, what is the function that returns the Hebrew date given the Latvian date?
I'm exaggerating a little-- but only a little.
The basis of most of these tests is simple-- rote memorization, and forcing the hapless test-taker to perform tasks with paper and pencil where they would ordinarily have 5 ORA books, a half dozen colleagues on AIM/ICQ/Yahoo! Messenger/MS Messenger to chat with, and Google.
Needless to say, this is not only unfair, but comically (tragically!) unrealistic.
Unfortunately, the only meaningful test of a programmer is the one thing they cannot do in an interview setting-- have the candidate perform a real, everyday assignment, with full access to everything they would usually have access to, without the artificial and performance-damaging stress of the test environment (remember, many of us get conditioned to stress out when in a testing environment. Remember all those horrid nail-biting Calc/Physics/Chem exams from High School and College?). But since that can't be done...
Personally, when I give interviews, my technique is to grill users on their general coding/SA philosophy, and their TRUE background-- that is, not only things they've done for corporations, but things they've done for non-profits, things they've done at home, things they've done while sitting on the john in Penn Station... It doesn't matter where you coded something to me. But unfortunately I seem to be alone with that opinion, and most employers only want to hear about things that you did in a commercial, for-profit environment.
A sad fact of the market nowadays is that a large proportion of job applicants are grossly underqualified. Most of my job, as I've explained to coworkers, is weeding out, for instance, Unix SA job applicants who've never adminned a Unix box ("But I have a certificate from Sun!")... programmer interns whose greatest programming achievement thus far is "I opened a Visual BASIC program's source code, and changed its background color"... and the like. (Both of these are actual examples pulled from my interviewing experiences. Scary.)
I personally feel the job of interviewing is easy, if you're a serious hacker yourself. Hackers can always recognize other hackers. Even though many of us lack much ability to 'sense' people (remember how many geeks are autistic, e.g. with Asperger's Syndrome or whatnot), a geek can almost always sense another geek, if they are AT ALL paying attention.
Of course, in some cases, The Boss specifically does not WANT a geek. If you are lucky, this sentiment will fizzle out before the end of the interviewing process, leaving you to select a geek for the job. But once, I recall my boss telling me she wants a "regular, ordinary" (suit-wearing) person to help SA our Unix boxes. The result was a disaster. We interviewed a number of of really well-presented, suit-clad, well-educated, polite young (and older) men-- absolutely none of whom proved qualified to even TOUCH a live Web site, let alone one of our size.
After sitting in on an interview, my boss admitted that I was right-- that looking good in a suit and having a few certificates from Sun does not a Unix SA make.
Anyhow, just my 2c... YMMV. Sorry for rambling.
Honey, I shrunk the Cygwin
Although this seemed hard when I first looked at it, I had had teaching in preparing a presentation as part of my CS course. In the end, I just picked a subject I knew fairly well (interprocess communication - I'd only done it a few months before), read over my old notes, prepared the outline of my presentation, and went for it. (I had about a week to prepare)
It must have worked, because they MADE a job for me :) [I didn't get the job I was going for, but they gave me a short-term contract to see how I panned out. Unfortunately, I became a victim of corporate shrinkage ten months later - LIFO :( ]
I am eternally grateful to them though, because they are a very big name in the computer business, and even having had only a lowly position there increased my marketability enormously.
Back to the topic, though... I don't see anything wrong with testing a person's competence. However, as someone pointed out previously, you're not in a real-life situation where you can't get hold of Google, &c. But... a true craftsman doesn't rely on others; you should be able to solve a basic problem on your own. I think it is unfair to insert incredibly difficuly and obscure questions into such a test unless you have access to the documentation. Not all computer people have immense memory skills, which is what you are testing in such a situation.
If I composed such a test, I would "weight" the questions so that the incredibly-difficult questions (which you would be hard-pressed to answer without a manual) had a LOWER weighting that the ordinary questions when answered incorrectly, but a HIGHER weighting when asked correctly. Say you have 40 questions, and a wrong answer on a normal question loses you two points, but a wrong answer on a difficult question is a loss of 1 point. Start with a baseline score of 80. With 10 difficult questions in there, this gives you a minimum score of 10 (all wrong) and a maximum score of 150 (all correct).
The idea being that, you are not penalised for failing to answer so heavily, but you are rewarded if you put the effort into the difficult questions and get them correct. Explain the scoring to the applicant in advance, and you also get an idea of how they prioritise problems (do they go for the hard, high-scoring questions first, or do they complete the easy questions, then move on to the difficult ones if time permits?). Of course, you could have questions which score higher than 2 as well, depending on the complexity of the answer...
I've only been given one written test, and test wasn't about my technical ability, and it was done on the east coast.
Now-a-days I think I'd come close to being offended if a company insisted upon a written test of my technical ability. I've been in technical interviews, and those are fine -- they confirm what I claim on paper. But I'm not a job hopper, I think that my steady employment coupled with my personal software development business should prove that I'm capable of working within a team and working independantly. The real question for the business is whether my technical abilities fit the need the business has and whether the cost of hiring me fits the budget they have for the position.
I guess the bottom line is that I have over twenty years in software development and systems administration in varied enviroments. I don't feel the need to do more than prove I can do a great job in the position. And that probably doesn't, for me, include a written test.
It works for me -- when I was laid off two years ago when the company essentially failed, I had a job five days later. When I took a new job three months later because of poor working conditions, my former manager was essentially willing to pay me anything to get me back -- neither the I nor the company was as willing. But in each case my salary went up quite a bit.
I guess what it boils down to is that while a written test might be okay in more entry level positions, I don't think it's appropriate for upper level positions. If it's a technical job, do a technical interview. Check references and former employers if you're unsure about the person's writing ability or his or her ability to work within a team. But for upper level posistions I do think written tests are inappropriate.
Sean.