Slashdot Mirror
Appropriate Interviewing For a Worldwide Search?
jellomizer writes 'I am a manager of a small Software Development department, looking to hire some more developers. By edict of the CEO, the search must be made globally, so we are dealing with different cultures and different ideas of truth and embellishment, etc. To try to counteract this, we give the potential employees tests where I watch what they do, to see if they actually know what they say they know. However, it seems a lot of applicants drop out when I mention that this test is mandatory. Is this a sign that we caught them in a lie, or are we weeding out good people where we shouldn't be? Would you be willing to take a test as part of an interview? If so, is there any type of heads up you would like to know beforehand to make the decision of whether to take the test easier?' What other difficulties have people seen while trying to hire from many different cultures?
would be to give them a real life problem, ask them to solve it, and tell them that they can ask you whatever they want to, because that's the way it works in real life. If they know the answer immediately, well ok, but really what you want to see is their problem-solving strategy. I firmly believe that it's not about what someone knows that makes them a valuable employee, it's how they figure it out. How they solve the problem. People who rely on the resources around them, generally speaking, are better to have around then people who think they have to have learned the answer in a textbook somewhere. If the nature of your job is such that answers are already known, then you don't need smart people. You just need workers. Such a test doesn't need to concern itself with being culturally sensitive.
I'm starting to think that our interviews here should literally be: give them a day's work and see how they do.
No, I wouldn't be willing to take a test, and I actually flat walked out on an interview in 2003 when I showed up and was told - by surprised - that I was going to be taking an exam. I was also then informed that the open position was for a junior position. When I expressed surprise at this, the HR flack's response was "Oh, didn't I mention that in my email?" She hadn't. Either of those would be sufficient for me to end the interview process, which I did.
Why would I refuse to take a test? Simple: if you're giving me a test, the usual reason is that I'm being interviewed by someone who does not possess the ability to discern whether I know what I'm doing/talking about or not. If that person is the hiring manager, then I certainly don't want to work there. Working for people who cannot identify competence or incompetence is not pleasant. If that person is not the hiring manager, I still don't want to work there: it shows they would waste my time by having me interview with such a person rather than with the hiring manager or any other person who can tell if I'm competent or not.
If more employers were able to test their employees adequately during screening, there would be a lot fewer bullshitters out there trying to claim they can do what they can't. Burn in hell you cert-chasers who don't know what you are doing!
Every employer who gave me such a test, I always got an offer -- usually a good offer. Some of us are actually good at working through IT related problems and solving them. Some of use are not and just want to coast through on bullshit.
There are very few people who feel that they are "above the test" and the eager ones actually say "bring it on!" Those are the ones you want.
As for setting up a "practical" part of a test? Absolutely! If you have the skills to build a nice one, do it.
Nothing gets under my skin more than HR people screening resumes of really good people because the right set of words didn't appear on a page. Every successful hire I have ever had was when another IT person was involved in the screening and interviewing.
Not having an answer proves they don't know how to use Google. It took me 5 seconds to find a good overview of what a c++ class is. If you were talking to me, I'd tell you straight up; I'm not good at regurgitating formal definitions, but I would tell you where to find the same article I am looking at, then riff on various real world projects and problems.
If you can't tell me, in very general terms, what a C++ class is, then you're not qualified to claim you're an expert on C++. It's that simple.
Yes, I do a lot of Googling around when programming to learn more, to find other answers to problems, etc. I also don't have the C++ operator precedence memorized, and refer to a table for that. But some things you need to know or else you simply cannot claim that you're "proficient" in the language. When the job req says "needs to be proficient in C++", then certain basic things like that you need to know.
I'm sure I could Google around, read a book, or whatever and put together something in Python pretty quickly even though I've never programmed in it before. But I wouldn't tell an employer that I'm proficient in it.
Really, who do you want to hire? someone who can tell you what a class is, or someone who can tell you about problems they have solved.
Are you trying to claim that it's OK to lie on a resume and claim knowledge of programming languages you've never worked with?
Don't forget, this particular job was a contracting job. Long-term employment was not to be assumed here; the company wanted someone who could sit down and start contributing right away.
If you are in a smaller organization, it is very likely that there will be periods where other skills are needed - such as interacting with customers (pre-sales/post-sales), design, documentation, etc. etc. So be careful that your are not screening for one-trick pony (coders) if there is any possibility that you will need someone with other skills as well.
It seems to me that if the job entails those responsibilities, that should all be stated up front instead of assumed. I wouldn't take a job that required a lot of customer contact; my specialty is software engineering, not schmoozing clients. Time wasted with customers is time that could have been spent productively. Find a different employee to do the customer-contact stuff; this is why humans invented the concept of "specialization of labor".