Slashdot Mirror
Testing IT Professionals On Job Interviews?
An anonymous reader writes "After having my university degrees, a couple of IT certifications, and over ten years of work experience in the industry, with 2-4 years of verifiable employment with each employer, working with a wide range of technologies, is it reasonable to ask me to take some test on a job interview? The same companies don't ask other professionals (lawyer, accountant, sales, HR, etc.) to submit to any kind of in-house tests when they are hired. Why are IT professionals treated differently and in such a paternalistic way? More importantly, why do IT professionals accept being treated less favorably than members of other professions? Should IT professionals start to refuse to be treated as not real professionals?"
It's also possible that the interviewers feel that specific IT knowledge becomes obsolete very quickly. If you've been around since the 80s for example, then the specific skills you had when you started are no longer relevant (general skills are another matter of course). If you haven't used a relevant technology that the employer needs in at least two years, the interviewers may feel the need to test you on it.
And it is so hard for your references to know if you're really any good or not because unless you're in a large technical group a lot of them wouldn't really know what it is that you actually do, or how to tell if you do it well.
Most companies won't provide a reference other than "Person X worked for us from (date) to (date)." It's just too easy to say something which could be misconstrued as being negative and used to sue the company which issued the reference.
You mean like with the bar exam, cpa exam, the useless PMP exam, certified professional engineer, etc.
Other professions are tested, but it is before the job interview.
Surely being given an opportunity to demonstrate one's skill/flair isn't disrespectful?
It depends on how it's done.
Exactly. I'm in the camp that says some sort of programming test is fair for any level. If you're really a "Senior software engineer" with "excellent $LANGUAGE skills" then writing something like fizzbuzz will only take you two minutes, right? The number of people I've seen come to an interview making that sort of claim who could not code fizzbuzz is scary. Perhaps unsurprisingly, my tolerance for taking this sort of test myself increased significantly when I crossed from being an experienced developer who just found them patronising to having the kind of role that also involves sitting on the other side of the table from time to time and seeing what some of the other candidates are like.
On the other hand, I rather doubt I'll ever be working for the kind of place that has a whole-day interview process that consists of solving an endless series of trivial programming problems, followed by a load of "Have you seen this one before?" questions like the 1/2/5/10 problem. These tests are only useful as a block for the low end prankster, not as a way of gauging how good someone competent really is. After the first couple, if it seems like there are going to be more, I will take control of the interview and, usually, end it shortly thereafter.
This is a valuable reminder that interviewing is a two-way process, and that those applying for higher positions with more responsibility should be entitled to ask "difficult" questions that any competent employer should have no difficulty answering, too. Just as a significant proportion of interviewees are a joke, so are a significant proportion of interviewers/employers. These days, I'll basically let a prospective employer run the first interview, but if I'm called back for a second interview so I know they are serious, I will ask to see a sample of their production code and a sample of their development documentation, I'll ask straight questions about their software development process, company culture and working conditions, and if I'm still ambivalent perhaps I'll ask to speak privately with a current employee who is doing a similar job to the one I'm applying for.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Lawyers, accountants and physicians are generally required to take a two-day or longer test before being licensed. Admittance into the tests usually depends on a thorough background investigation, including fingerprinting before the candidate is given an "entrance ticket." In addition, there are usually proctors, selected from current members of the profession, to make sure no one is cheating on the test. If IT professionals had passed state and/or national tests this rigorous, their credentials would probably be accepted also. As for salespeople, their exam consists of just one question, "Would you sell your grandmother to get a contract?" Negative answers get you thrown out into the street.
I have used "effect" as both a noun and a verb for the majority of my life, in both the written and spoken word.
"to effect" is a verb. The only problem is that it is synonymous to "to cause", and not to "to impact".
"The effects of an earthquake can effect large numbers of people."
Which, when replacing "to effect" with its synonym, becomes:
"The effects of an earthquake can cause large numbers of people."
Yes, I assume that after an earthquake, there's not much else to do until the electricity comes back on.
The "correct" form however, offers no justification for itself other than its own inertia.
The "correct" form offers the justification that it has a completely different meaning than the incorrect one. That should be sufficient.
Why not get the compiler to do the work for you:
$ gcc -o test -Wall -W -ansi -pedantic test.c
test.c: In function `main':
test.c:5: warning: operation on `i' may be undefined
$
Lo and behold. It's undefined behaviour.
$
i = 0
$
And look. I don't get the same results as you. (Probably depends on the precise version of gcc and also maybe the optimizations selected.)
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.