Hello DetachedDutyScout, and welcome to the Monastery!

I can’t answer your specific question, so I hope you’ll forgive me for instead offering an anecdote from my own experience:

As we neared the end of our final year, my fellow BInfTech students and I received an invitation for a job interview with a company specialising in C++. Some of us decided to apply. I remember arriving late (the company was about an hour and a half’s drive away from where I lived, and I missed the turnoff!), and being given an initial IQ-type test. After that the exact sequence is hazy, but I found myself in a full-on psychological evaluation outsourced to a professional psychologist who was on site for the purpose. “When did you last cry” is the one question I remember from the battery of similar questions I was asked. After that (I think) I was given a written test using a database-description language I had never heard of. At last, I was ushered into the inner sanctum to be interviewed one-on-one by the big boss. When this interview (a harrowing experience) was over, and I was ready to make my escape, I was dumbfounded to be told: “You’d better go and get some lunch before we complete the interview process”!

Looking back, I don’t know what I was thinking, but I obediently went off and bought lunch and then returned. I was shown over the office (a separate building) where the programming was done. I noted that the programmers all wore ties, and most of these were decorated with illustrations of Dr. Seuss’s Cat in the Hat. Then I had another one-on-one interview, this time with my prospective team lead, who, despite his obvious youth, was introduced to me as a C++ guru. (He also happened to be the son of the big boss.) When I finally emerged from the interview process, I was limp and somewhat dazed, and the day was nearly over.

The following day I was offered the job: entry-level salary, minimum 2 or 3 year commitment from me (“we’re not going to waste our time training you only to have you leave before you give us any value”), MS certification to be obtained by me on my own time. I politely declined the offer.

I’m not making any of this up.

It seems to me that the battery of tests, interviews, more tests, more interviews, etc., etc., told me far more about the company than they learned about me. I’ve never regretted my decision.

DetachedDutyScout, if I were in your position I would probably take the test, if only to see what it was. (You can always decline to submit an answer: “If that’s an indication of the kind of work I would be doing, I have to say it doesn’t interest me.”) But I would look carefully at the company before committing to working for them. Not saying they wouldn’t be good to work for — they might turn out to be great employers — just saying, don’t let the interview process intimidate you into forgetting that you are also interviewing them as to salary, working conditions, etc.

Anyway, thanks for letting me get that off my chest — I feel a little better now. :-)

Cheers,

What company? What city/location? Are you sure it wasn't some matrix movie?

Sorry, no names, no pack-drill. But it was no movie. The people at the company concerned took the whole process very seriously.

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

I also remember a recruitment process where I had to go though nine interviews. In the end, I was not taken. It turned out it was probably good for me: the company was the French subsidiary of a rather large British company. A couple of months later, the British company was bought over by a very large French company (the world leader in its industry sector) and, soon, a number of the local employees of the British subsidiary were laid off. Rather happy that I did not make it in the first place, but, still, nine interviews, it is almost a nightmare.

with a few questions directly out of Damian's "Higher Order Perl"

Thanks for the correction...Mea Maxima Culpa!

I am highly involved in the recruitment process in my company and, believe me, it is hard. It is quite hard to determine with a so small interaction when somebody is going to fit in your company, the team, and the particular post.

Also, some times there are too many actors on the company side with different interest and grades of involvement and everybody has an opinion about how the candidates should be. Sometimes it is like an onion, the good layers (i.e. your future team) are hidden below the bad ones. At the end, people struggle to do what they can and some companies get to do it well and others just don't.

Is that representative of what working at that company would be? IMO it says something but I don't think it is enough to rule a company out. At least try to meet your future boss and team!

As others have said, if the company is this deep in the analysis, either they really know what they're doing, or they have no clue. If they really know, they will be able to cite statistics on false positives and false negatives, describe the mitigation process (correcting for the falses, as well as avoiding discrimination and other biases). They should be able to estimate savings over a more conventional system. And they should randomly take a few fails through to the next step (blindly), to evaluate the metric, or it will be "correct by definition".

If they don't know what they're doing in the interview process, chances are good they don't know about much else either (though it could be just an HR wonk driving it). Update: Fixed typo.

I went through a somewhat difficult interview process about two years ago. The first part was a series of Perl questions that I had to answer within 24 hours .. challenging, but fun. The second part was an hour with the Director, on a shared screen; while he watched, I had to complete four exercises. I think I got two of them done; one of them was with a regular expression that I couldn't get right. It was frustrating for me, and probably not much fun for him.

I understand the Timed Exercise thing -- but I'm one of those people who did poorly on exams (all closed book, in my day), but very well on assignments and labs. I just don't perform well, developing something complex, while someone else looks on.

I prefer the smaller questions when asked in a live setting -- during a session like that, a different interviewer asked me, "And how *else* could you do that?", which was great, because when you're writing code there are lots of ways to get the same thing done, some clearer, and some not so clear at all. At one point I wrote

defined $foo or die "Foo needs to be defined";
[download]

I'm also happy to write something 'within 24 hours', because that's a reasonable facsimile of the work environment. Having to debug a regular expression while a Director looks on is not really representative. IMO.

Good luck with your job search!

For one job, I took an "programming aptitude" test along with 20 other people. For my current job, I was given an 3-page exercise that asked questions to test my familiarity with both EDI and Perl - "what does this code output?", "spot the error in this 204". The aptitude test was timed, the pop quiz was not (well, not explicitly - if I had taken more than 20 minutes I suspect I would not be working here). I consider myself fortunate that I have never encountered any "If you were an animal ..." type questions in interviews.

I don't think this really tells you much about the working environment. Everybody is looking for the magic formula. This will help them establish you have the technical chops for the job. If I were trying to fill a lead role, I think I'd be more concerned about your leadership experience.

Of course, most of us around here have been on both sides of “that desk,” and so we can attest that both sides are no-fun.   One of the biggest problems that I see companies rather-consistently making, is that they search for (say ...) “Perl experience,” instead of, “experience!”   Hence, they write “difficult” tests, about a particular language or tool, give it to you examination-style, and demand that you must provide an answer that they can subsequently “grade.”

I take a different approach, and would recommend it:

1. “First, tell me about a program that you have written for another employer ... it doesn’t matter which language was used.   Tell me what this program does, and what role you played in it.”   Now, listen patiently, maintaining eye-contact if s/he maintains eye-contact with you, and looking slightly to one side if s/he doesn’t.   (Don’t expect a computer programmer ever to make eye-contact with you.)   How quickly and how effectively does the candidate communicate that answer to you?   By what method(s) do they attempt to do it?   Are those methods effective?
2. Next, briefly and generally describe a problem that your team is actually facing, give a high-level explanation of it, and ask the candidate what s/he would suggest and what sort of role s/he might be comfortable with, in working with such a project.   Take a slightly more active role, trying to steer it into a high-level technical discussion, avoiding unnecessary mention of particular Perl packages.   How well does the candidate engage in that discussion?

And the proper thing to do, if you are on the other side of the desk, is self-evident.

Yes, I’m most interested in “soft skills.”   To me, human communication, and congeniality in the face of pressure, is far more important than one’s technical command of this-or-that language or tool.   And, as I said, years of actual experience.   If you don’t yet know Language-X, then I can teach you that (or, you can pick it up yourself, over the weekend).   But the fundamental skill that is needed is the ability to talk to people and to develop and build a technical framework, and/or to look at existing source code, divine what it actually does, and develop a change which neither breaks it nor re-writes it.   “I’m not running a school, so I’m not going to give you a test.”   But you should, by now, have a long list of professional references.

And, as a candidate, you need to swiftly make the decision, “Do I actually want to work here?”   Almost everyone works in a cube-farm, of course, but there are pleasant ones and unpleasant ones.   Almost every team uses some kind of methodology to their madness, but methodologies preached from a podium only get in the way.   And so on.   “Trust your gut,” don’t burn any bridges, but also don’t put yourself in Hell.   (You’ve already been there enough times, aye?)   ;-)

I possibly cannot give any advice , i am a novice with just two years of experience . But yeah i my interview process consisted of written tests for c & english and math. After that it was one on one with a senior architect where upon learning i was from biotechnology background he didn't probe much into OO principles and actual coding tests .He just asked about my other skills and was impressed by my hardware/OS knowledge .Finally he said you seem to learn quickly so that's all is required.

Two years & two accounts later i have worked on j2ee,spring & struts framework,perl,shell scripting,sharepoint,web developement,frond-end UI.Still trying to learn :)