Appropriate Interviewing For a Worldwide Search? 440
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?
It's mandatory here. (Score:5, Interesting)
I know there are definitely people who refuse to take a test out of principle. I'm not really sure what principle this is; maybe it's that they do poorly on testing in general. But we have been burned too many times by people who know how to talk the talk but turn out to have very little real skill. Sometimes too, there are multiple similarly skilled candidates to choose from. Giving them a coding test; especially an open-ended one can give you some insight into the sort of developer they are. Some people will be a better fit for the team just out of the approaches they tend to take toward problem solving.
Also, tests must be taken in-person. We do not allow phone or otherwise remote test taking. There are a lot of really unscrupulous agencies and individuals out there. Some of them have you interview with a different person than who they claim to be, including the person who will take the tests if any. The guy completely aces your questions and really knocks your sock off with his knowledge. Then he shows up, and his voice sounds different. You put him in front of a keyboard, and he asks you which key is the "Any" key.
The thing is, it's no offense meant to the interviewee. Indeed, just as it protects our interests to be certain that we hire a qualified developer, it's in your interests too (if you are a qualified developer) - the fewer and more quickly we sort through the deadbeats, the faster we get a job to a person who deserves it. It's not that you'll necessarily lie to us, it's that there are plenty of people out there who will, and until we really get to know you, the only way to tell the difference is to require you to answer questions that only a qualified individual is able to.
I don't take test as a matter of priniciple (Score:3, Interesting)
Sorry, but when I did I saw them go screwy so many times. almost always of you didn't do it the predetermined way you were wrong, or if you answered with an answer someone didn't know, you were wrong..
Plus after 15 years I find it a tad insulting.
Re:A good test (Score:4, Interesting)
hire them as a contractor for 30 days.
I've been hired into bigger projects many times that way.
Global search? (Score:2, Interesting)
Companies claim that they can't find good help domestically, but what they're really saying is that they don't want to pay for home-grown talent.
Sorry for the rant.
Re:I don't take test as a matter of priniciple (Score:3, Interesting)
You find it insulting that a total stranger doesn't take your word for how good you are? You must get insulted very often.
I mean, what's there to be insulted about? They asked you to do a beginner's test? Well, if it's clearly below your level, then that's a good thing for you -- now you know that you're not the one they are looking for.
Now, if I came strongly recommended by somebody, and they give me a test, maybe the guy who recommended me should be insulted. Me? Never.
90 day probey (Score:3, Interesting)
give them a day's work (Score:4, Interesting)
I knew a guy once who, when he got a large fungible job in, would put out a want ad and "interview" people exactly as you describe. He'd literally get hundreds of hours of free labor this way, and the bastard knew he'd never be called on it.
It is for exactly this reason that I don't work for free during interviews. If my prospective boss isn't sharp enough to know that I know my stuff after a brief conversation and a look at my credentials, then I'll happily work for his competition.
A lot of people do lie about their qualifications. (Score:3, Interesting)
Knowing this, having interviewed a lot of people and having known a lot of interviewees, I wouldn't be insulted to take a test. However, its also true that a lot of the gimmicky kinds of questions that are asked on tests don't show very much about a candidate's depth. Certainly a test shouldn't be a primary criteria.
Re:A good test (Score:5, Interesting)
I'm starting to think that our interviews here should literally be: give them a day's work and see how they do.
At my current job (Which required relocating out of state), I was basically given something like this. After the initial round of phone interviews, I signed an NDA, and was given a design specification for part of the product that I would be working on. I was told to ask whatever I needed clarification with, and to keep track of my hours so they could pay me when I was finished, regardless of whether I was hired or not. After I thought I was done, I submitted my project. They had a few revisions that they wanted, so they sent it back to me to see what I did with it, and presumably see how I handled needing to make changes.
Once they approved my work, I was flown on-site for the final interviews. During those, they asked about my project, why I had done things certain ways, and different ways that I had considered completing it. The project took me about 25 hours of work to complete. The day after the interview, I was offered the position.
In the end, the project that I had worked on was incorporated into the software that we released. From what I've heard, all new-hires go through this process, all with a different project to complete. It seems to work well for the company, we've got a very high retention rate.
If they don't take the test, forget them (Score:4, Interesting)
If someone doesn't interview (or worse, complete an interview) because of a test I don't care how smart they are. They're too much of a prima donna. I've been in situations where an interview had tests that were way beneath my skill level, and in those cases I've either known immediately that the job I was interviewing for wasn't for me, asked the interviewer if there were more high level jobs available, or helped them fix their test. (In one case the test had questions that helped answer previous questions, so I helped them fix it.) In all cases I impressed the interviewer enough to get the job.
Test the right things, consider legal issues (Score:3, Interesting)
Testing isn't necessarily a bad idea, but it can create problems as well as solve them. In most software development environments, any testing should usually be used to weed out unsuitable candidates rather than to produce a single number that will be used as the primary hiring guide. Other things like interpersonal dynamics can also be important, for example. Multiple-choice tests are probably the least useful, because they test specific bits of knowledge rather than broader concepts; that may be useful in a classroom where you're testing the student's knowledge of a specific curriculum, but most real-world software development positions (other than perhaps the very most entry-level jobs) are more about design and problem solving and not so much about things like the details of a specific computer language. Essay tests of whatever sort would usually be the most useful, but also the hardest to design and grade.
Even worse, if you aren't careful, in many places and depending on whether you are a public or a private entity, you can potentially open yourself up to things like discrimination lawsuits if you don't end up hiring whatever person received the highest score on the test even if they don't fit some of your other criteria very well.
I would certainly not want to give a test that wasn't in person - there are far too many ways to get scammed: For example I've had someone ask if I could "help them out" with an online employment test - not just asking me for one or two bits of information, but essentially asking me to take the whole test for them! If you are doing a "worldwide" search, that creates problems for a small software group - the cost of flying a number of candidates to your location can be astronomical.
FWIW.
Re:A good test (Score:1, Interesting)
Coding interviews always seem to involve moving targets for me ("How would you solve X?", "Simple, do Y". "Wait, do it without using any storage", "Ok, try Z". "Now do it in constant time without using any storage on a quantum computer running Windows 3.11..."), and the most difficult part for me is always justifying the solution to the interviewer rather than coming up with one (because coming up with one is kind of a subconscious thing... it's just the way I think).
But I'd have to say the worst interview questions I've received were at Google, of all places. One interviewer in particular stood out: he was expecting a solution in O(n log n) time, I managed to solve it in O(n) time, and yet he was not satisfied until my solution (and its complexity) mirrored the one he had in mind. I forget the exact problem, but I think it was something like trying to determine the distribution of characters in an ASCII string. Really simple to do with or without sorting, faster to just tally up the occurrences (like counting/pigeonhole sort), would only take 1k of memory to do my way, yet he kept insisting that I quicksort the string and count up the adjacent characters instead.
Real world, rather open-ended problems are the way to go. Let the candidates use Wikipedia, books, or other resources. Take the development time, complexity, maintainability, and readability of their solutions into account. Basically model the environment that they'll be working in if you hire them.
Re:A good test (Score:5, Interesting)
He spent another hour debugging the problem then turned to his interviewer and said "I figured out what the problem was, but if you want to know, this will be my first day." They hired him on the spot and payed him eight hours for the interview.
Re:A good test (Score:4, Interesting)
so somebody who is actually learning outside of their everyday requirements, somebody who is raising their qualification and is able to apply this knowledge when it is needed... is the worst candidate for you ?
you would be more interested in somebody so narrowly focused and unwilling to learn new things unless forced, only because he doesn't "browse the internet" ?
i would say that an employee that has the desire to learn, has learned something outside their primary work requirements AND knows how to apply that in real world scenario is the most valuable one of those 3 generalised categories.
Tests are a waste of my time and yours. (Score:2, Interesting)
A test is only as good as it was designed. The question is, how do you know if you're measuring what you think you're measuring?
One time when I was applying for a job I was told I was going to be tested on writing fast SQL code, so I should be sure to be up on it. I heard from one person at the company that this was something they deeply valued. I bought a book on optimizing SQL and started reading it. After a few days of reading I decided fuck it, why should I be ALREADY be spending my own time doing what this company desires? There was no guarantee they'd hire me anyway, so there's a good chance I'd be learning all this for nothing. If that's such a big deal to them it's something they need to train people for, not expect everyone to know a relatively specialized skill up front.
In other words, the fish bowl works both ways.
I have rejected test interviews (Score:2, Interesting)
I'm not very good with people, but I've still got a proposal for every interview with no test or a decent one, but nothing fruitful ever came from interviews with demented tests.
I think the best tests come from interesting questions that will catch the horrible people on the spot, and give the good people opportunity to shine, like "What's the difference of ++x and x++ in C?". An average person might say "they're different in when x will be incremented", but better people can answer in more details, maybe even including details on how it used to make performance differences in for loops, but doesn't anymore, and why that is so.
On a higher (but still technical) level, you probably just want to know who likes to know the technologies that are important to them in depth. With that in mind, I think it's a lot more useful to ask "Tell me about a detail of your language of choice you think I don't know about/that surprised you in your work." than telling somebody to create a very small program in an hour or to solve a bug in a program they've never seen.
Of course, that is considering you want good programmers to work on a mid-sized or even larger project. If you just want some guys to program for your sweatshop, my honest advice is you hire average skilled, unambitious people, or people who have been a few years at other sweatshops.
Because you aren't as smart as you think (Score:5, Interesting)
Many moons ago when I was doing coding jobs I had a series of interviews that required me to code stuff to demonstrate what I knew. I was looking to move away from my current job into new areas and didn't know how they worked but they all seemed to ask the same thing
1) Code something
2) Take a coding test
What I learnt very quickly was that lots of people are really looking to hire people not quite as smart as they are. I knew this because I had three interviews where the following happened
Interview 1:
Set an "impossible" task to code (in C) an address book and calendar solution with a GUI (this is the mid-90s) in 6 hours. No internet connection and no reference books.
3 hours later I set off to find the interviewer in the pub.
Interview 2:
Set a series of questions around "write the most effective code to do X".
There were 10 questions and I answered them in 10 different programming languages (Ada, C, Prolog, C++, Eiffel, 68k assembler, LISP, SQL, COBOL, Fortran) and the chap interviewing me didn't have a clue if I was right or wrong.
Interview 3:
They had a major bug in a current release, my job was to find the bug and explain why it happened. I knew free work when I saw it. It was a big C programme and it took me 4 hours to find the bug (pointer referencing problem). I wandered into the office of the person setting the "test" and said...
"How much to tell you the answer"
I didn't go for any of these. What I went for, and what I have done since, is go for the company that set me an abstract test that asked me to design a system which had a number of constraints. They didn't want code, just to see the conceptual model that I would create. When I joined I asked why they did it this way and the answer was enlightening....
"Because we want to hire smarter people than we are. If you talk code then its just about optimising, but if you talk about the abstract then its about thinking. We want people who give us answers we think are wrong and then they explain why we are wrong."
The key point was to give people a limited time (15-30 minutes) to understand the problem and propose the solution. You want people who are agile and quick, not people who can sit on their arses for 6 hours doing a troll job.
If you want to hire people dumber than you, set complex long tests that "only you" know the answers to. If you want to hire smart thinking people set very short tests that challenge their abstract thinking.
Re:Good developers dont have time to take many tes (Score:4, Interesting)
One C++ shop I worked in we used to have a short sample C++ program (~~ 2 pages long) that was deliberately written to contain a large number of problems, many obvious and some quite subtle. It was an "Animals" style example program so manifestly not production code. We asked candidates to examine the program and find as many of these problems as they could then suggest better ways of achieving the same thing.
We weren't terribly interested in how many problems they actually found but were vitally interested in how they approached the analysis and how deeply they understood object orientated design and the C++ version of that paradigm.
It was great fun to write and we eliminated quite a few posers with this tool.
Re:A good test (Score:2, Interesting)
I then want to know how they deal with some prick arguing with them that their chosen solution isn't very good.
Personality issues are pretty fucking key in most roles and companies...
I do tell candidates both before and after that if I argue with them they should just take it as part of the process, to try and calm them.
In general, try to think why you are being asked a question, and maybe why the interviewer is disagreeing with you in a demonstrably correct answer. Of course that applies in life as well as job interviews.