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.
The problem you're going to run into is that developers in high demand are well, in high demand. Their time is valuable. Every hoop you make them jump through is fewer jobs they can apply to (if they even bother to apply anymore, they aren't just thrown job opportunities like cans of free beer), so that makes your job less attractive. Unless you can hire 1000 people, why are a large number of people going to waste their time taking these tests? Perhaps you could do the test, but only after you've narrowed your applicant pool to a small number of people, and only if your job entices them enough to not apply to 4 or 5 other jobs in the time it takes to apply to yours. I do like your solution though of actually watching them write the code though, because that does prevent them just copying and pasting other code and sending it to you.
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.
Slay a dragon... over lunch!
Most people don't do testing until the 2nd or 3rd interview. Such candidates have a pretty good idea if this is a company they'd like to work for, and if not, they refuse the interview. They don't have to spend that much time taking tests, because presumably they only end up in a few final-round interviews before they find a job (unless the testing outs them as a fraudster).
Slay a dragon... over lunch!
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.
The Kruger Dunning explains most post on
The business owner was looking for a new receptionist, and couldn't decide which of they applicants to hire, so he decided to do a test. He accidentally "dropped" a $100 bill in front of each of them. The first just handed the money back to him. The second took the money, then came back later saying "I invested that $100 you dropped in oil futures. Here's your $100, plus $50 profit." The last slyly pocketed the money and didn't say anything about it.
Which one did he hire?
The one with the biggest tits, of course!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
My guess is some of them are worried about being caught in a lie, some of them are having their pride hurt (not sure why), and some of them just don't have the time to waste on taking a test for a job they might not even get.
I think another problem you are going to have though is, unless you give them a fairly trivial solution to solve, they are probably going to need to think about (and or research) the problem for a while. Not only think about it, but take some time to actually complete the problem. You couldn't give a test like "write me a molecular dynamics simulator in the next 15 minutes". You could test their ability to know syntax and functions off the top of their head, maybe their general coding style, or watch them do some simple refactoring after they finish a quick once-over, or maybe you could GIVE them code that needs to be reorganized and watch them reorganize it (which I think is a better test of usable development skill than the quick once-over). I would try to find ways to test things like the latter, and not things like the former so much. I think some of your good coders are going to be put off by the idea of someone trying to measure how quickly they code, or if they know syntax off the top of their head. I tend to know a lot of the syntax but I suspect plenty of programmers need to reference a manual for obscure stuff and I wouldn't hold that against them as long as their design and problem solving ability is good. Measuring the last couple things is harder to do.
Bullshit. If you want the job, you do whatever the employer asks to prove you have the qualifications. Unless you work is universally known, like John Carmack, or Linus Torvalds, you're never too good to take an entrance exam.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
Make them do the "Which feminine hygiene product are you?" quiz on blogsbook.
Small dev shop interviwing internationally due to CEO mandate ... yeah, how do we know the submitter isn't lying? We need to test the submitters.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Jeepers, this chaps my ass. Is it really so hard to find good help locally? Foreign workers are seldom the bargain that they seem to be.
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.
Best regards.
Good luck with eating the department.
Also, tests must be taken in-person.
The article is about a worldwide search. Who covers the airfare?
If you want to test just capacity for solving problems, don't make it depend on fine language understanding, some good foreign developers could be fluent in english technical written language and dont do so well on full language, or spoken one. Test as possible what you really want to know, not putting limitations on things that could or could not matter in the job.
Or maybe since you are not planning on being their slave you go work for someone else?
You want me to work during the interview? You can pay me.
I did the test they sent. Then they wanted to have two developers sit there and watch me. I just didn't feel comfortable with that--it creeped me out. I declined for that reason more than any other.
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.
In our company, we work with offshore programmers.
Our selection process includes a mandatory test, during which we assess the candidate on several points, mostly: IT Skills, ability to understand requirements, motivation. In order to avoid cultural issues, we tend to focus on facts and we try to avoid questions which may lead to a culturally biased answer. For instance, we would ask: "please explain me how you will implement such feature" instead of "did you understand what I mean".
The test is a simple project, and the candidate can work on it at his/her own pace. They are followed by a project manager as in a real work environment. Its duration is normally one week as candidates usually have a day job. We renumerate the candidates for the test they take with us.
The recruitment process has been found to be effective in most cases, allowing to effectively select quality programmers. We found that there are enough programmers ready to go through our selection process for us not to worry about the one refusing to take a test.
Exactly. Anyone who "refuses" to take a test for something as important as a career change is probably going to "refuse" a lot of other stuff once he actually gets in the door. Someone who is "too good for tests" is generally trouble in the making.
... I say hire them on a 90 day probational period ... if you don't like them then fire them and try try again. I think that works across all industries. You get to see them at work, you get familiar with their attitudes and working habits, and you always have a scapegoat that if you just don't like them, you can fire them.
I would have 0 problem taking a test, but too many times I have seen interview "tests" that are nothing more than a quest for free labor.
Unless a serious offer is being made I am not taking a test.
You have a dumb CEO.
Weed out the morans, the liars, and the people who think their "degree" from UnheardOfCollege in UnheardOfMajor along with a list of every popular language will be trusted.
99% of the time it's a code monkey from India who desires to simply get a job for Visa status, wiggle into a role of writing/supporting web applications in 1, 2 languages tops, and then do a mediocre job of it due to lack of actual knowledge and prior experience.
Any filter will weed out some percentage of good people. The question is really in the caveat, whether you are doing so unnecessarily. That depends on the resources available to your search and the position you are trying to fill, among other factors. Personally, I don't mind taking the odd test, though I find it a bit grade-schoolish when potential employers call it a test. I've always called such "technical evaluations" when interviewing candidates (six of one, I know), and made sure that (1) the questions were interesting to the candidate, and (2) that the candidate clearly understood the questions were intended to elicit insight into their thinking rather than grade spot performance. The former of those reflects another aspect of a search, one that I feel is more important than test/don't-test, and that is Accurate Position Description. Almost every job posting I read asks for qualifications that, if satisfied, would put the rest of the workforce to shame. Focus on what technical aspects the position should fulfill, rather than listing ridiculous qualifications and proficiency in a cadre of technologies in the hopes of hiring the "perfect" person. (I once read an advertisement for a position that required 20 years of professional Java development experience. Think about it.) There is rarely a perfect person. Decide what the focus of the position is, advertise for that, and ask interesting questions within the focus in order to evaluate capability. My two cents.
If I were applying for jobs, I'd be dubious about one that required an explicit "test" as part of the interview process, since it's hard to know what you mean by "test". Are you going to test my typing speed, or whether I know obscure language trivia (quick: Where was Bjarne Stroustrup working when he invented C++? How do you pronounce "Bjarne Stroustrup"? What does "restrict" mean in C?), or whether it's really a standard interview in disguise.
A normal technical interview process really should be a "test", for all intents and purposes. It's fairly easy to put a candidate in front of a whiteboard and figure out whether the candidate can write a function in your language of choice. (At least, it's easier to test coding ability than many other professional jobs.)
You mean like a free consulting day for the company? That's a half empty glass. Maybe you should look at it as another company you can put on your resume. :)
I work alongside a culture who literally wash their a** in the same sink (skid marks and all) in which I brush my teeth. Do I need to change their culture to make a good worker?
Also, "What Colo(u)r is your Parachute?" has, for decades, stated that 97% of ALL job applicants lie on their CV/resumee. I will only work for a company whose HR sifts through the chaff to find my 3% CV/resumee, before taking a quantitative test (usually full of human errors). The company has to be right for me, too.
I've never taken a job at a company that requires a second or third interview. If I have to make more than one trip to your campus I'll take another job before you get a chance to make an offer. Likewise, if you have any testing that requires more than a trivial amount of time on my part, I'll pass on the "opportunity" to waste my time at your company for free. If you want me to spend my time you'd better be paying me for it.
When I'm interviewed, I solve the tests without even blinking. If the offer afterwards suits me, it's fine. If not, well... I never bother to consider'em again. Simple as that.
When I'm interviewing, I sometimes ask the applicant to solve small puzzle(s). Such as: "say that 0080 is a number in octal, could you please rephrase it in decimal?" (hands up who got the joke :) .
Presumably you know enough about your test to know how well it correlates with normal domestic resumes, yes? -- in which case, just skip the test for domestic applicants.
Or if you don't know how well your test correlates with the more common measures -- then yes, as a prospective employee, I wouldn't trust your test.
The reality is that of 100 people who apply, only 50 know how to successfully reverse a string.
Only 30 know how to use recursion to solve that problem.
Only 10 know how write recursive programs traversing binary trees.
Only 5 know how to use polymorphic methods in Java to solve little toy graphical problems.
Only 3 know how to create classes that can be used inside HashMaps.
Only one knows how to create proper unit tests.
Exactly how much productivity do you think is possible to get out of an interview candidate? In the world of interns and off shore labor, if you think a company is going to get a positive net gain in work done by 'stealing' work from interview candidates, you're retarded.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
I have been put in such situations and I just politely end the interview process.
I don't work for free, and anyone that would expect me too is not going to be an employer I want to do business with.
If a serious offer has been made and you want me to write on a whiteboard, great. If you want me to email you a finished project that you get to keep, you are going to have to pay.
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.
He put his boots up on the table and made a face. "The sig," he smirked. "You can waste your life in search of the sig."
One thing employers should do more often is talk about salary up-front, so prospective employees don't waste a lot of time with testing and interviewing just to get an insulting low-ball offer. This has happened to me several times, and it's annoying. This doesn't mean testing is bad; I had some simple tests in the interview for my current position, and they gave me a very generous offer unlike other firms in the area.
I've found too many companies are tight-lipped when it comes to salary; they want to waste a LOT of your time in interviewing and such (and their own employees' time too), but then when the hiring manager says "he's great! hire him!", the HR person wants to give a lowball offer, and refuses to bring it up to anything reasonable even when you have a much better offer in-hand. If these companies would just state up front what their salary range is, we wouldn't waste all this time and effort.
Meanwhile, these tests do NOT need to be difficult or long. I had to help phone-interview some contractors at one job, and I came up with some very simple questions to ask them. One was, "In C++, can you tell me what a 'class' is?". Several contractors who stated "expert-level C++ knowledge" on their resumes couldn't answer that basic question. So you don't need to give them a 2-hour test; just some simple questions, maybe some short code samples with errors in them, etc. to see if they're completely lying about their credentials or not. So many people lie on their resumes (and this is definitely cultural; I saw this mainly in people from India), it's really important that you screen out the liars from the people who can actually do the job.
"Are you a virgin?"
Circumcision is child abuse.
This is about IT and not about programming, but the best question I was ever asked in an interview was the classic POSIX locking/deleted file/du vs. df question (each reports different amounts of space used, why?) because it gives the competent interviewer a chance to instantly evaluate your level of knowledge. Some people say "oh yeah, that one" (which wasn't me at the time, heh) but the responses tell you how familiar people are with basic commands they should know a lot about, and what their problem solving skills are like.
I think the people who say that they don't have time to take tests are bonkers. If it's contract work, then you should be hiring people based on a trustworthy recommendation; otherwise, testing is a necessity. By the time you actually interview face to face, you should have a clear idea of whether you want to test someone, or from the other side of the coin whether you want to be tested. I've never gone to an interview without some preparation over the phone, including some actual interviewing. To do otherwise is to potentially waste a lot of everyone's time.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
You've got to be kidding me. If I have to come to a location multiple times for a job interview, I'm probably wasting my time. The only way I'd bother is if we start discussing salary right away, so I don't find out at the very end that this employer is a low-baller.
In my 11 years of experience and many, many job interviews, I've never had to come back to a place for a second interview. If the employer can't tell if I'm a good fit in one visit, they're doing something very wrong.
Most "software engineers" can't solve simple problems in a reasonable time frame, don't check corner cases, and failed to retain computer science
basics from school.
Mediocre ones fail to solve problems until some one steps in and does most of their job for them. Average ones are an order of magnitude less productive in terms of lines of code (which is a bad metric) than exceptional ones. Exceptional ones produce more maintainable solutions, make more efficient software, have lower defect rates, defects more likely to be caught by internal diagnostics, and shorter mean times to repair their bugs.
Unfortunately, those things don't show up on resumes so you need to test.
Many technical people fill their resumes with buzz-words but don't actually know what's on there. You need to validate that too.
I ask all interview candidates a few simple coding problems regardless of years of experience. I ask simple data structure questions. I ask for technical details surrounding things they've done. People with surprisingly good back grounds (high GPA at a good school for newer graduates; lots of projects) fail.
One was too offended to continue talking to us; although I'd rather find out that some one is too good and experienced to follow process (bug reporting, coding standards, design cycle) before joining the company.
I worry when I interview at companies which don't check.
I've worked several places that had some sort of practical skills test for programmers.
I consider them a strong success.
There's a surprising number of people that can talk a really good game, but fall apart when asked the most basic actual questions. And, conversely, people who aren't extroverts or for whatever reason aren't stars in the verbal part of the interview, but clearly know their stuff when given a written test. It's a really good way to fairly judge technical skills across candidates, and weed out the fakers before you have to fire them later.
And as an employee, I like working with smart, competent people. I know how much, from experience, a bad hire wastes my time and ruins morale, so I'm happy to work for places that put out effort one way or another to not enter into this trap.
Anyone who'd refuse on principal, I'd worry is either a) faking it, or b) too arrogant to work well with others. A good candidate is happy to prove that they're a good candidate, and won't have to work with idiots.
A test isn't the _only_ way to do this. Any sort of nice, concrete technical grilling will do. But for a programmer, it _must_ involve actually writing code of a non-trivial nature. You can't believe resumes - even if people aren't lying, a Senior Programmer at one shop may only be barely competent at another, and not even realize that the bar is set differently.
Of course, the quality of a test can vary just like the quality of an interview question, but the goal is good for the company _and_ the employees, and in my experience it works better than most techniques.
Now, if your shop isn't terribly compelling based on product, and you're desperate to not turn people away... well, you probably should be looking for places that feel like they need a test to screen out unqualified candidates, so you can stop hating your job, and not worry about fixing this particular problem. :)
-- Kate
I imagine sending out the same requirements sheet to 100 interview candidates lets you get positive work out of them if even only 1 does what you needed.
When so many of the job postings today want you to have PhD in their field as well as 10 years experience using programs that have only existed for 5 years you have to lie. The honest non-lying people simply don't apply. And if you're willing to lie on one thing, you're willing to lie on another. I'm confident that if you auditted all the resumes and then verified the claims the majority would contain lies. The first step to fix this is to post realistic job requirements.
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.
It's been standard procedure at both of the companies I've worked for to give some sort of "test"
My first job out of college asked for a simple algorithm, it was a sort or search, can't remember which. There's an hour given and you have full access to the web, so even not knowing the language I was still able to accomplish the task. Apparently many fairly senior people couldn't perform such a simple task in the time given, while I was able to weigh multiple algorithms. This surprised me.
My current job (I've only been out of school for 2 years) also had a technical interview but it was less test-like. They had me sit at a laptop with the screen projected on a wall and asked me to design some fairly simple classes. They wanted a dialog so they could see if you were thinking ahead. They also asked some questions such as which scenario would you use this algorithm in and asked me to think through a logic problem.
Both of these companies were filled with some of the brightest people I've met in my life who were enthusiastic about their jobs and were high performers. I did an internship where there were only meet and greet interviews and no problem solving, and the people who were hired were barely competent at their jobs. I feel like if you are interested in a job creating software, you need to enjoy programming, so a technical interview shouldn't be difficult or offputting. If you're relying on your personality and charm to get you in the door and then hoping to slack off, you'll be deterred by a challenging interview.
I hope that helps. I know I'm pretty fresh in the industry, but I've heard too many stories about incompetent senior software engineers.
One of my first programming jobs had a logic test as part of the application process. That seems like a good way to weed out the people who can't think on their feet or are too important to jump through a hoop or two, without insulting anyone with a VB quiz or free labor.
Even though aptitude tests are pretty annoying, I really see them becoming more important since it's getting harder and harder to judge a person by their resume.
Literalism isn't a form of humor, it's you being irritating.
I read about this a few months ago, but a few companies have implemented the idea of "Extreme Interviewing", modeled after eXtreme Programming. The general idea is that you pair applicants with existing staff members and have them work together through a series of exercises. Your existing staff is told to identify candidates based "on their ability to think critically, ask good questions and finally on their ability to make their partner look good." The exercises are modeled after activities that would normally be performed in the workplace and position they're applying for. There's usually 3 or so exercises, where the applicants are mixed up between different staff members.
Using this approach you can easily identify candidates who are willing to help other team members as opposed to making themselves look good, and those who are willing and able to draw on knowledge from their teammates. Some places will select candidates for a 2nd interview with the same layout, but involving actual projects and tasks for the company they're applying to. Best of all, no one feels like they're taking a test, your staff get involved in the hiring process and help ensure your company culture stays intact, and you get to measure performance metrics that actually matter as opposed to how well someone can regurgitate definitions and method signatures.
Of course, this might not work as well from a remote location, but if your company does regularly telecommute between development locations (mine does) you could adapt the process to include that.
Totally, if you are offering less than current_income + 10%, why should the interviewee waste his time?
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.
Anyone worth their salt would take the test. I've known too many programmers that have been around for 10+ years that can't code for shit. Most of the people that say they have been programming for "15 years", mean that they started when they were 15 and are now 30, but have been only been doing it professionally for 8. Age and "experience" don't mean anything in this field. Just because you've been around doesn't mean you know what you are doing. I've been on interviews in the past where there was a simple test, such as a SQL query, class inheritance, etc and had no problem showing them I knew what I was talking about. As a former person that also did the interviewing, I've seen many people that claimed things on their resume, but when asked to prove it, they couldn't. The majority of companies out there incorporate some sort of test to weed out the out right liars from the people that may have embellished a little. If a person has a problem with taking a test during the interview, they are not worth your time and can look for a job elsewhere.
I've been given a bunch of tests. In some cases the questions were,
"How would you optimize this code?"
My thought was, "Why did you write such shitty inefficient code in the first place?".
Another "How do you reverse a linked list?"
My response, "LinkedList.Reverse()". My thoughts "Why would you reinvent the wheel?"
After 10 years of doing this stuff professionally and 20 in total, I find it quite insulting that someone would make me take a test. Anyone who would lie about what their skills are needs their head examined anyway. Any smart person can learn new technologies rather quickly anyway. I learned C#, SQL, and ASP in about a week each. Furthermore, you can find out if they're good or not by talking to them for about 30 minutes. An industry that is over 50 years old, and some people just don't get it and never will.
... in order to feel the need to take the test. I've lived in my house for 19 years, and I haven't missed a payment yet (knock wood).
If they think I got the Master's in SW Engineering by being bad at tests, there is so little respect for my degree that my potential employer is without potential.
I do a software test for my candidates.
I hand them a small (40 line) program that is broken. Since most of my work involves code maintenance it's real world enough.
I tell them up front that the object is not to fix the code per-se, but rather to walk me through them debugging it. I've hired guys who couldn't solve the problem because they showed enough promise that I wasn't worried that I could train them, and it was obvious that they could think well.
We have a total of 4 hands on tests. Three on hardware, one on software (R&D lab). Worked out well for us so far.
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
I'll explain and answer almost any question you ask, but I will not take a programming or psychological test for a job.
The only questions I won't answer are extremely personal and where I'm under contract not to reveal details.
Programming tests don't allow me to use my normal setup - which actually has reference material available.
Really good people are hired by reputation quicly and never out of work any longer than they want to be. They don't take tests.
I do like your solution though of actually watching them write the code though, because that does prevent them just copying and pasting other code and sending it to you.
Copying and pasting code amounts to 90% of even the best programmers' jobs. Other than some aspects of GUI design and input validation (which even then just means "tweak the conditionals of what you have", not "write an input handler from scratch"), if you sit down at a blank editor on anything but a toy project, you either work in academia or need a much tighter deadline.
And there, I have my biggest objection to "testing" applicant, particularly in a vacuum. In the real world, I program with access to huge libraries of functions and at least half the time, a web browser open to look random things up as I need them. Yeah, I could rewrite Windows from scratch if you give me 500 man-years to do it, but do you want to see if I can really do the job, or do you want to see if I happen to know the prototype for some particularly obscure network calls off the top of my head?
People pay me to solve problems efficiently, not because I've memorized the latest edition of K&R.
(and for the record - Yeah, I pretty much do have the prototypes for the entire standard ANSI C library memorized, but would prove just as valuable if you wanted me to program in any language, including one I've never used before)
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.
I got my job (in avionics software) partly because of my score on the test my boss gives. Now I correct them for him, and it's hilarious, because there are a lot of people out there who can talk big but are good for nothing.
I'm now retired, but all the way back to my first tech job interview in the '60s, the interviews have included tests of my ability to perform as needed.
If one cannot test an applicant one is seriously handicapped in making valid hiring decisions.
--
Tomas
University Place, WA
You will lose some good people who do not want to take the test. But without the test, you might hire an incompetent employee. Which is worse?
Personally I'd take the former failure mode. In that case your job search just takes longer. I'd rather that, than hire a bad employee.
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
If you want just tech, ask just tech questions. If you want a rounded flexible employee, ask tech and behavioral questions.
An interview is a test, there are questions and better/worse answers. Just tech questions will give you a score but ...." will expose experience and give insight.
"Tell me about a time when
TMATW you worked on a project that was behind schedule.
TMATW you disagreed with the team.
TMATW you made a mistake.
Clear judgement, not score, is the best result from an interview. But you know what ? good hiring managers are hard to find :-)
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.
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.
AccountKiller
The vast majority of my applicants are foreign-born, and freshly or recently moved to Australia. So far the only Aussie to apply to my most recent position was referred by one of my Aussie devs.
This CEO is obviously preparing for an interplanetary coding battle royale, pitting the best coders from our world against the best from theirs. Which planet does the best coding? There can be only one.
I don't like taking tests simply because they are stressful. The more stress you put me through verifying my skill prior to hiring me, the more I will assume you will stress me out in the workplace, and, correspondingly, the more I will expect from you in exchange. If you insist on heavily testing your employees, be upfront both about the number and nature of the tests you administer and about the compensation for the position. If you can't find anyone after being forthcoming with this information, you are either asking too much or paying too little.
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?
I won't venture a guess as to whether you've caught them in a lie but unless your test is seriously overbearing, you're not weeding out anybody you shouldn't be. Competent developers serious about finding a job won't balk at an interview merely because you ask for a demonstration.
I will say this though: be honest, be open and be brief. Tell them that the point of the test is to eliminate folks who talk the talk without walking the walk. Encourage them to take a copy of the test with them so they can use it to improve on any issues they weren't prepared for. And don't ask 100 boring questions. Something as simple as, "write a function in C to reverse the characters in a string," can be surprisingly revealing.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
The answer to this question is extremely useful in assessing the candidate's knowledge of and maturity in software development. For example:
And so on. Obviously there are no right answers, and it's critical not to be biased in favour of one's own pet methodologies. What you're looking for is someone who takes intense interest in not just coding, but in the entire process of developing quality software.
You've got to be kidding me. If I have to come to a location multiple times for a job interview, I'm probably wasting my time....
No, you're probably wasting ours.
In my 11 years of experience and many, many job interviews, I've never had to come back to a place for a second interview.
Then you've probably never held a senior position at a LARGE company. Multiple interviews are the norm. There's the preliminary interview with HR, then you'll probably get interviewed by the country/regional director, one of the VP's, or someone on the board, then you'll probably get interviewed by the leader of your team/group and other members of the group. There's at least 3 interviews.
Of course you won't even be CONSIDERED for the position by HR if you haven't taken a number of tests by outside consulting firms that point out your strengths and weaknesses. In fact, continual testing is a part of any serious career.
But then again, I guess we're not talking about the same salary range either.
Seven puppies were harmed during the making of this post.
Yes, this process does weed out the self-important people.
'I am a manger 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.
So you are already changing tests to account for different backgrounds, yadda, yadda, yadda. Exactly how much of the company is also going to change just to accommodate someone? I assume you are making the ability to speak and write in English mandatory? Are you going to make any concessions considering you are going international with your search? Sounds like management just wants an excuse to pay less for the same work, not to say it doesn't happen for other reasons but work done by foreigners isn't always the same or better. You get what you pay for.
this nation, under God, shall have a new birth of freedom. -- Lincoln, Gettysburg Address
The reason is I've been through a lot of interviews that consisted simply of a few questions like "open a connection to an SQL database in C++". Now, what's the answer to that? Perhaps "Okay, right after you tell me what library you're using and give me its API." or maybe "Do you really expect a good developer to remember functions they used just once? If you coded opening connections to databases more than a couple times per project, you're very likely doing something wrong."
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.
... experience, 3 years after Oak became Java. Pick a language, pick a big number of years, shove the two together in an ad, require that applicants also be liars.
www.profilesinternational.com
The guys developed this buisiness just for these reasons. Major unviversities use this service to hire programers to college deans without potential liabilites that may come in the selection processes - descrimination, etc. All candidates take several tests and interviews to determined ethics, compatible personalities, and experiances. Background checks are performed. They have several international offices through out the world, with web pages in several languages.
Then you've probably never held a senior position at a LARGE company. Multiple interviews are the norm.
Dude, this is Slashdot. We're talking about hiring IT people and software developers here, not CxOs and VPs. You're in the wrong discussion.
Let's face it anyone who can memorize some flash cards can become an MSCE. And the attempts to create a software developer certification are even more laughable. Consider also that in those industries where the certification means something say ASE, the test that one has to pass to be certified is hard and includes real world problems. In the absence of a meaningful certification you have to test applicants some how and in a field that includes a fair amount of creativity it is hard to be objective. Still in my experience I have worked with "software engineers" with 15 years of experience who could not choose an appropriate data structure for a simple problem. So I think a simple real world problem done in person is very reasonable. Understandably, you should give every applicant for a given position the same problem both for fairness and so you can compare results.
In Japan we have a variety of certifications that usually cover any sort of test, but often certain companies will give small tests to weed out candidates in lower positions. Tests are usually for lower positions only, and often have nothing to do with coding or aptitude but rather creativity. Even then, this is only for people applying to entry level positions - the tests are often waived if someone is recruited (in the case of software development nice demos, winning contests, or holding a lot of licenses/certifications alone can get you recruited somewhat easily). For higher positions most coders would be insulted if you asked them in for an interview and handed them a test. Experienced coders especially will hold esteemed positions and pride comes along with that - so a test at that point would be for the most part insulting unless you made it a particularly interesting test. I have a feeling this is something that goes beyond just Japanese culture. Many coders would rather submit a demo with source than take a test, and being handed a test many would find insulting.When I say demo, I should note I applied for a few positions that used demos as tests. These were often "one-day demos" or "6 hour demos", where you were given something to do, write the nicest code you could to achieve that and package it all up within that time limit. Not finishing wasn't a disqualifies either, and the themes were always just vague enough to be really interesting but still easily achievable within the time frame if you were actually a capable coder.
"different cultures and different ideas of truth and embellishment, etc."
I read that a few times and it keeps coming out as "Foreigners bother me and I think they are all intrinsically dishonest by virtue of being foreign."
A childhood watching The A Team? A lifetime watching Fox?
I'm based in the UK but grew up in South East Asia.
That's gotta count for a little bit....
The interview process he describes is pretty much exactly what everyone goes through to work at some large development shops. I know for certain that Valve does extensive interviews for any potential candidate. If the interview process is mediocre, so is the company.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
I work in the electronics industry. Every time I apply for a job they always give a test based around what type of electronics the company does. With larger companies they're certainly a lot easier. I work for a smaller company right now and we repair motor controllers. The test I had to take at my interview was based around MOSFET's. There were other simple things, like reading a resistor, doing voltage dividers, solving a series - parallel circuit, etc... But half of the test was on what we work with the most. Knowing this information before going on the interview helped. Not only did it give me a better idea of what I'd be working with on a day to day basis, it also allowed me to potentially brush up in an area I may not have been so great with.
If you're going to test people, let them know what the test is on and what it will be like. If they decide they don't like that, well that's that. For those that are interested in having the job, they will at least take the time to prepare themselves in some fashion.
The caveat to this is to keep in mind that some people are just bad at taking tests. Some people might need to brush up a little. You need to consider how well they did during the interview process along with their test scores. A bad test score doesn't necessarily mean to not hire the person. Look at what they did wrong and look at what they did right. If they have the basics down, yet they a little rough around the edges with something more advanced, they just might need to get their feet wet again in that area to pick up the pace.
If that's what you think, you're not a developer. Writing the initial code to solve the problem is typically about 20% of the total effort of any task, and no interview code I've ever reviewed has been production ready code, or even the kind of code you're write for anything other than a prototype. Development man hours are not fungible or distributable.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
But the interviewer doesn't know that you're divinely inspired. If you are in such high demand that you can get any job you want, even in today's economy, then you don't need to even interview as everyone will be calling you instead.
In the real world though, most people have encountered people that sounded great on paper and who had great recommendations, but were lousy in practice. People will lie and embellish, and prior bosses will lie because often company policy is to never geed bad references. This is especially true I think in a "global" search. There are people who will say yes if you ask them if they can do brain surgery if the need arises.
The issue isn't to get you to do free work, but to evaluate you. I have never seen a "free labor" test. There is not enough time in an afternoon to get free labor out of a candidate.
No matter how smart you are at solving cute interview problems it's takes a loooong time to get good at writing large/complex programs in a grown-up programming language.
And yeah, most of the drop-outs were probably liars.
And most of the others will probably be deluded about their skill/talent.
No sig today...
You don't understand the concept of 'recession' do you? Or the idea that someone might hate their job more than they love money? Or that someone might want to switch to another company because of a belief in what they do?
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
Explain in advance that testing will be done, and give the candidate a good idea of what to be prepared for.
Keep it to a minimum, keep it as short and minimal an inconvenience as possible.
Don't spring the testing on the candidate at the interview, or try to treat it as if it's part of the interview.
It's dishonest to ask them to come meet you, and then to ask them to do a task that you had not informed them they would be asked to do.
It will cause undue stress and disdain because they don't know what to expect, or because you're putting them under unreasonable conditions for a meeting.
Interviews should be laid back, so the candidate can be relaxed and comfortable, don't ask the candidate to do a lot for you in a short amount of time.
No timed 200 question essay/long-answer tests.
Maybe a 2 or 3 short question / short answer "Assessment"
They should be asked orally and they should be questions that don't require the candidate to do elaborate math in their head or use scratch paper / calculator / etc.
The candidate may not perform well because they are not mentally prepared for technical assessment, their mental energies are concentrated on interviewing for a position, not development minutia.
The most extensive interview process I ever had was with Intel. It lasted a whole day, but no more. Of course, that was a junior-level position 9 years ago, so I can't say how it'd be for a senior-level developer position.
And then you spend several days or weeks sifting through the 100 responses, integrating them into the code base and running regression tests, until you find the one that actually works. If you had that much time to spare, you could have fixed the problem yourself.
Stay away from pure code tests. Asking a person how they would solve a given problem or a puzzle is a great idea. But have them explain to you in their own words how they would solve it and don't focus on a particular programming language. The reasons are:
A) Programming languages can be learned. You don't want to rule out people who are great problem solvers just because they don't know your favorite language yet. And don't let them pick their favorite language because you may not know it well enough to judge their effort.
B) You want them to demonstrate good communication skills. In the real world good programmers have to deal with people (Customers, Mathematicians, Human Factors Engineers, Electrical Engineers, Safety Engineers, etc...) who aren't coders.
Provided you are looking for good test passers, that is.
Call your local university and ask this question of someone in the anthropology department. Someone who specializes in cultural anthropology.
Anthropologists study different cultures with the same intensity as your average Slashdotter studying operating systems and programming languages. Few others are as well-equipped to answer this question...
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.
An Eye for an Eye will make the whole world blind - Gandhi
Have you read the papers lately? Unemployment at a 26 year high? You'd be considered lucky if you can keep your current salary if you got laid off and had to go elsewhere today.
And employers who will abuse their developers time.
And since this is /. I will tell you that no one has simply drawn a line between the AC and diode symbols, but I would give them points for smugness if they did.
Thus leaving Monkey Island in the blissful tranquility of ignorance.
For God doth know that in the day ye eat thereof, then your eyes shall be opened, and ye shall be as gods
The last 3 guys I interviewed were recently laid off (the economy is bad did you hear?) and would have gladly taken a 10% pay cut ....
Preparation is key. The last position I was interviewing for I spoke with the Director of IT on the phone first. I spent most of the time asking him questions about his company and the way they had things setup and what they were looking for. He spent time asking me about my experiences with the technologies that his company has already implemented and is planning on implementing in the next fiscal year. I learned enough about his company and what they were up to in that thirty minute phone conversation that I decided I didn't want to go onto the next step. I thanked him for his time and wished him luck on finding a qualified candidate for the position.
The technical workforce marketplace has evolved. Ten years ago you could get a job with a bunch of certifications, or even just some experience. Today (and especially in this economy) there are so many people looking for work that employers have the luxury of screening. When it comes to IT work, it is very important to find competent people. In many cases, the foundation of the company rests in the hands of the IT staff. If the systems don't work or the developers aren't competent, the company will have a hard time doing business.
It shows a serious level of immaturity and a severe ego problem to get in a huff about pre-employment screening and tests. Temp to perm, or contract to full time positions are quite common. If you have the skills to get the job done then you rarely have anything to worry about. Despite all of the concerns over unscrupulous employers who will take advantage of workers (sure, there are a few out there), the large majority of companies don't want to invest the time in breaking in a long chain of employees. They want to hire someone who is good at what they do and who has the ability to help the company succeed. Once they find that person, they will do whatever they can to retain that person.
One quick addendum to my prior comment: timing is important.
If you ask me to complete a test as a gatekeeper function to granting an interview, I'm not going to waste my time on you because that tells me that you're full of crap. My resume should tell you enough to determine whether you want to speak with me on the phone. That call combined with my resume should tell you enough to determine whether its worth your time to give an interview. If it hasn't then I'm not the right fit for the job and its time for me to move on.
This means only the desperate applicants will spend their time on the gatekeeping test. And why do you think they're desperate?
On the other hand, once you invest 30 or 60 minutes of your time talking to me and discussing my skills, I know you're serious. It's then well worth my time to demonstrate why I'm a better choice than the other candidates.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I was test manager on a 50-person project. The development manager and I noticed that we had managed to hire a bunch of people who couldn't code their way out of a loop. I guess this showed that we weren't good interviewers. What we did about it was to write some tests of our own and give them to candidates. I never had a person decline to take a test. We did find that our tests discriminated quite well between candidates, and we found that we ended up happier with people who did well at our tests even if they couldn't talk the talk well.
All of our tests were very straightforward, no surprises or curve balls. And since we were the ones who had written the tests, we knew the material well. Some of the questions, we knew there were very specific answers to. Others, we just asked, "Here's a thing. Say something interesting about it." We calibrated the tests by giving them to current employes. We revised them until the people who were doing good work did well on them and the people who were doing poor work did poorly on them.
The better candidates pointed out errors in the tests. The best guy was someone who obviously thought a lot like me. After 10 minutes, we both got so involved in solving a coding problem that we forgot we were in an interview. He was a great asset to the project, at least until he decided he wanted to work nights so he could have another job during the day.
Bottom line: there's no way I'd hire a programmer or tester without seeing them program or test. Or in the ideal case, both.
(We made sure that the content of the tests was not related to the content of our project, thus avoiding even the appearance of asking for free work, unlike the slimeball referred to above.)
If people from India lie on their resume, it's because hiring managers are retarded and believe any bullshit if it's on someone's resume. I can say that I have a PhD in Rocket Science from MIT or whatever the fuck that sounds credible. No, the way to judge your candidates is demo reel.
For God doth know that in the day ye eat thereof, then your eyes shall be opened, and ye shall be as gods
First, your CEO is an idiot and I would suggest that you yourself ought to be looking towards your employment prospects elsewhere.
Second, the first question on the test should be: Are you eligible to work in the United States? If no, stop now and please leave quietly.
Third, the next question should be: What is your speaking, reading, and writing level of the English language?
Last, give them a programming problem of the sort that they ought to be able to solve given their proposed position in your company and allow them 2 hours to solve it. If some candidates are getting back to you with solutions in 15 minutes, make the problem harder. If everyone already working for you can solve it in the requisite 2 hours and none of your candidates can, keep looking.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
MIT makes you write an essay and do a personal interview even for candidates for an SB from foreign countries.
Atheist: Buddhist in a Prius
I find the all day interviews where you have to talk to 12 people at the company a huge warning sign that the "company" is really a cult of personality looking for a convert, not a worker. You can almost see them blinking out "help me" in morris code as they interview you.
If a company doesn't trust one or two people to find someone to figure out if someone is a good candidate in an hour, then just flee. This is a huge warning sign that nobody in the company has any authority or responsibility at all and the only decisions that are made are made in large orgiastic group think meetings.
Wanting you do more than token coding is another huge warning sign. If someone wants you to archetect out some huge design for them or design a large useful object, then what is happening is that you are doing their work for them. For free. If you don't get the job, bill them for your time.
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.
So many people lie on their resumes (and this is definitely cultural; I saw this mainly in people from India)
that is an illegal observation (nationality bring a protected status). You have to find a legal thing the people who share his culture have in common. Maybe they all like bad Song and Dance flms? Show them Moulin Rouge (not actually a Bollywood film) and ask them how they liked it?
I like your method. Put them in a situation that relates to the job you expect them to do.
I have been employed by three companies in the past 22 years. Each time I moved on, I left on good terms with my current employer and listed my previous boss on my resume as a reference. In my current position, I do the technical interviews, generally over the phone or a lunch meeting. I usually prepare for the meeting by contacting the listed references and asking them about the applicant. If someone lists three college buddies, or three junior coworkers, or three people from completely non-related fields, then I have a pretty good indicator already that they were not respected by management or senior developers in their last job. I find a loose correlation between the quality of the references and the quality of the applicant.
In my interviews, I generally give a simple requirement and ask how they would solve it. I don't care if they know the details to implementing the latest and greatest algorithms or programming methods. I care how they approach the problem, what questions they ask, and how they think through the solution. Also, within ~10 minutes of questioning, you can determine if the applicant really knows programming or just knows buzzwords and for loops (and if you can't, then perhaps you are the one who just knows buzzwords.)
Talking to and assessing references can give you a good indication of work ethic and behavior.
Talking to and assessing the applicant can give you a good indication of knowledge and talent.
Between the two, I've been very successful in hiring quality developers for our company.
For example, an open-ended test that allows a programmer to solve a problem is good and proves the candidate can, you know, PROGRAM. A non-programming test (like multiple choice) that drills you on obscure topics of a language or requires that you have every design pattern known to man committed to memory---not so useful. In the end, a lot of BAD programmers do really well on those sorts of tests but fail to have a clue when asked to implement the simplest feature.
But what if they want you to meet multiple people? This happens a lot when scheduling conflicts make it impossible to do one all-day interview.
Personally I go out of my way for a potential company if I like what I hear throughout the interview process. I can come back more than once. In fact I did two phone interviews with the same company and I'll be flying down there Monday to do an on-site interview. I get paid a very good living and I understand that my employers expect the best so I'm not too put out by it. A great job can turn into a lifetime position so one might as well put as much effort as needed.
I just finished an interview that included a 'hands-on' test where I controlled the interviewers PC with webex. They were standard UNIX commands for troubleshooting, etc, nothing too intense. They claimed to be conducting the interviews this way for the same reasons as stated in the article.
There's a difference between someone who's laid-off and looking for work, and someone who currently has a job but is open to other opportunities.
Many companies seem to prefer candidates who are currently employed for some reason, and the longer you've been unemployed, the more likely you'll be to take a low-ball offer, but the less interested companies will be in you.
Anyway, in my own experience, I got most of the low-ball offers way back before the recession started. It's not something that's only recently started. A lot of companies (especially smaller ones) are just plain cheap. Worse, they have unreasonable expectations: they seem to think they're going to get top-notch candidates with below-average pay, even though there's plenty of other firms in the area that pay average or better. It's one thing to be cheap, but it's just insulting to make candidates jump through hoops to prove themselves as top quality, and then give them a piss-poor salary offer. If you can't pay much, you should state the salary on the phone before the candidate even shows up in person to meet you, and you should have low expectations for the quality of your candidates.
Yes. There are a lot of crappy tests out there. That doesn't mean testing in general is worthless.
The cake is a pie
Not a problem. How does zero dollars sound? Don't let the door hit you in the ass..
I'm 13 years in and I know one thing - the more money you make the more they expect. So expect the interview process to get more thorough throughout your career. They don't give six figure jobs to people that can't be bothered to show up more than once.
I had to help phone-interview some contractors at one job, and I came up with some very simple questions to ask them. 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.
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. Personally, I stink at answering those sorts of questions. But, but after 20+ years of programming, I can say I have never been fired from a job, and every job I have left has retained me as a telecommuting consultant for at least some time. That should tell you more than how well I retain book definitions.
That said, it really depends on what you are hiring for. If you just need a cog to drop into a 100% coding position, the "test" route might work. 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. The parent did say contractors, so he probably does just want the specific skill. The rest of what I said applies more towards employees.
This issue is a bit more complicated than you think.
Good programmers *never* copy and paste. They move the code into a function and call that. (Or otherwise refactor.)
The cake is a pie
and stop wasting our fucking time. That's all this is about and you know it.
I completely agree about the salary discussion. I've got a pretty good job now, in a company that pays a substantial annual bonus. Make it worth my while up front.
But, I'll do your "what is a class" one better.
We mostly do C in a Unix command-line environment. I usually preface this by saying that we need to do some basic validation of knowledge, and please, don't be insulted by the questions. Then I ask...
1. What does an asterisk (*) mean in C? Any correct answer (multiplication, pointer dereference, pointer declaration, etc) is acceptable.
2. What does "static" mean for a variable in a function?
3. What does "static" mean for a variable not in a function?
4. How do you list the files in the current directory?
5. How do you change to a different directory?
I had one interviewee who, despite a fantastic multi-page resume featuring Unix, C and C++ everywhere, could not answer ANY of these questions in the phone interview. Needless to say, we did not have him in.
There was another one who sounded like he was reading the answers off something (remember, these are phone interviews) and he couldn't manage to actually explain what he meant - just repeat the same words in a different order. Once again, not invited in.
The preferred solution is to not have a problem.
Asking them to sit down and whip up a simple app in an hour is not unreasonable.
Otherwise go for a 90 day trail period or contract to hire.
But, you are doing it wrong.
>>ask them to solve it, and tell them that they can ask you whatever they want
Chances are, if you are the hiring manager, keyword being manager, you won't have a good answer to any important questions I have, and in fact will just give me bad information and make things worse.
This is software right? You do have a plan right? Just like the guys who built the building you are sitting in? Are you content to think that the guy who physically placed the rafters over your head was able to solve a tricky issues with those on the fly?
>> How they figure it out
Ya, now you are creeping me out, they figure it out with experience, intelligence, reason, knowledge, critical thinking, skill and intuition. Critical thinking is nurtured more in some cultures than others and intuition, a combination of all of the above attributes, is highly valued for some work.
>> How they figure it out
I don't' think you can evaluate that with a physical test, that's what the interview is for, to get an idea of peoples thought processes.
Can I bum a sig?
... where i run an in-house development shop we are actually obligated to recruit internationally for most positions, so we have seen it all.
A couple of wild generalizations:
- Eastern Europeans welcome testing - they would rather let their code do the talking over trying to sell themselves via a phone interview
- South Asians sometimes get themselves in over their heads in verbal interviews, with a cultural predisposition that it is rude to say "no" to anything, then once they have gone too far it could be rather humiliating for them to be tested on something they really can't do properly, so they will sometimes decline further consideration or just disappear.
- Testing should always be done, if the skill is quantiatively testable. A qualified candidate might in fact be suspicious of an international recruitment if it seems the selection process is not sufficiently thorough
- Sometimes the biggest hurdle is getting the best candidates to pick up and move to a different country - make sure that you don't waste time on someone who is really never going to leave their home country, but thinks its kind of exciting to do the interview process. (A good indicator is to early on ask if they have ever worked overseas before, if not, beware.)
- Brainbench.com offers some good screening tests.
(I think your CEO is on to something, by the way - nothing stirs the creativity pot better than bringing different cultures/backgrounds/techniques together!)
As someone who seems to be professionally unemployed (and, apparently, applying to the wrong jobs/companies), let me share my experience with interview tests.
Basically, I've experienced three basic problems with tests. They are:
1) Tests/questions which have absolutely nothing to do with the posted questions - eg. desktop support type questions for a developer position, and other similar absurdities.
2) Tests which ask information that you would only come into contact with if you did that exact, specific job, or one very similar to it, currently or recently - and even in that case, things which are on the fringe of common/daily tasks. For instance: writing a script (on paper) in VBscript to collect CPU performance metrics. This kind of thing is going to clean out a lot of competent, skilled candidates.
3) Tests which are very good, but I did poorly on due to insufficient specific domain experience/knowledge. However, given the nature of the position, the questions were overly complex/indepth. Eg.
4) Tests which are actually very good, relate to both the advertised job description and the position as it is understood. These are the ones I've done well on, invariably.
5) Thought-process/problem solving exams. These are also very good. They contain hypothetical technical scenarios, psuedocode/classes and the like to see how quickly/well you solve problems.
A large part of it depends on your specific niche experience and expertise. The #4 "very good" tests were, admittedly, right up my alley as I'd applied for those specific jobs due to familiarity with the topics. I'd say that, if you can pull #4 and/or #5 off, don't worry to much about whether people turn you down.
Honestly, I wish more employers would do pre-interview skill assessment tests. I'd have a much better chance of landing a job, if that were the case. There are entirely too many bullshitters out there holding (partially due to managerial/bureaucratic incompetence), applying for, and getting jobs in IT (largely due to the very nature of how rapidly things in IT change). Buzzword compliance/insistence is a bit of a contributing factor as well, I'm sure.
I know that I -have- overlooked positions due to a required 'test' before, though. They've been jobs where I know I can do the job, and likely be fully up to speed within a week or two (at least as the job has been conveyed - I adapt quickly), but the IT Manager has some sort of over-inflated idea of what the position entails (and I know I won't get the position) or it's evidence of an over-inflated company bureaucracy. I can see (and have seen) both those things scare people away regardless of competency.
Oh yeah, and don't be one of those pricks who makes a person take a test before you've actually reviewed their application, or after they've shown up for an interview. Please.
If your test doesn't suck, you're prompt in replying to employees you are interested in, and make the test accessible to them (ie before traveling to interview), I see no reason why you shouldn't keep testing.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Translation: "We wan't to pay 3rd-world wages."
Table-ized A.I.
I have 20 years of experience and a decent CV. I take requiring mandatory tests as either an offense (implying wouldn't be honest about my track record) or as a business full of bureaucracy. I will take neither at this stage, thank you.
How many tests does upper management take, btw?
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".
I think the ones who drop out at mention of a test are the ones you do not want anyhow. I have been tested plenty of times. And I test candidates myself also. Come up with a good test with real world problems and give everyone the same test. I encourage them to explain how they would find out and still solve the problem even if they do not know the answer off the top of their head. I usually give closed book tests and make them simple enough to pass without needing reference material. I do not ask about nitty gritty specific mundane stuff that no sane person should have to memorize. No questions about obscure gnu ls command line options or similar nonsense.
For technical jobs you have got to test. I have not tested before and regretted it. Now I always test. It is the only way to weed out the bullshitters. One technical person can usually interview another technical person and know who is a bullshitter but sometimes management will really like the person for one reason or another. Failing the test is very good ammo for not considering the person.
The ones who won't take the test are the ones you don't want.
Did you even bother to read the post you just replied to? He said, "Totally, if you are offering less than current_income + 10%, why should the interviewee waste his time?". If the candidate is unemployed, then he doesn't have an income, and "current income" = 0. There's no such thing as a "pay cut" if you're unemployed.
But if the candidate is currently employed, it's insulting to offer them a low-ball salary.
You are not hiring 007 or a fighter pilot.
I tested 160 on the "vanity" online IQ test.
But to do that. I had to take about one and a half times the allotted
time, so my score would officially be invalid. So I'm potentially
very intelligent, but a little slow and ponderous in my reasoning.
Also, in one of those "program this in front of me" tests in an interview,
my brain froze (looped?) due to the stress of the situation.
Now if we'd had a leisurely conversation about systems architecture
trade-offs, or explored a problem and solution requirements space
or a tough trade-off decision tree through socratic
dialectic, I might have wowed them, but it was not to be.
And I even knew that the answer to "How would you move a mountain?"
is "It's already moving. Please clarify."
Where are we going and why are we in a handbasket?
that "human" never meant to be
no one works for places that never tolerate anything
even human brain never works at 100% only for memroy tolerance
best managers never ask for 100% best
that's the art
If I interview with a company that asks me to rate myself and does not attempt to objectively assess my abilities, I politely excuse myself at the next possible opportunity.
People are not accurate in rating themselves. (See the Dunning Kruger Effect.)
I have been the technical person whose insights are always ultimately ignored on several interview panels, and I have seen that managers generally are completely unable to determine which candidates are confident because they are good and which are either confident because they are ignorant or their confidence is completely unrelated to their aptitude. Actually, managers are usually more impressed with those who are over-confident because they are ignorant than those who have aptitude.
I figure if they are not doing a good job assessing my abilities, if I were to take the job I would be working with a bunch of confident but ignorant programmers.
Go green: turn off your refrigerator.
Hell if I know how to reverse a string in place. I'll freeze if you get me to even try. I'm 1) left handed 2) a poor handwriter and 3) sometimes easy to frazzle. Get me in front of a whiteboard and ask me a stupid question like that and I'll freeze.
It is a stupid question anyway. What does solving it really mean? That you are good at writing bit-twiddling code? Screw that. Ask me to solve a problem. Ask me to sketch out a high-level view of the solution. Maybe a couple traces of code tossed in.
But you ask me to fucking reverse a linked list and you are looking for a code monkey who cannot think and cannot solve real problems. If that is what you want, so be it. But it isn't what I want. I solve real problems, bit twiddling is for the machines to solve.
They probably do not architect their systems and their programs leap back and forth between fixing high-priority bugs (due to lack of proper design) and adding high-priority minor features (that sales already promised were there), and they really need programmers to do quick work under stress and unrealistically short time frames.
They and you are all glad that they did not hire you.
Go green: turn off your refrigerator.
Although I don't particularly care for the idea, I'd much rather take a skills test than what I get at most places, which is a drug test and a credit check. A test of job skills is actually relevant, and I don't think it's unreasonable for a potential employer to ask an applicant to demonstrate that they can do the job. The only thing I find genuinely objectionable is when a company isn't up front about the hoops they expect applicants to jump through. If you expect your applicants to be honest with you, the least you can do is to return the favor.
Proud member of the Weirdo-American community.
No wonder they all have second interviews - who'd want to work with a toolbag like you?
I don't see why you're concerned with cultural differences. If a candidate says he can do something but can't show you that he can actually do it, why would you consider hiring him?
Is it just me, or are most "Ask Slashdot" questions artificially overcomplicated?
I find these tests of memory not problem solving ability - I find they annoy me for that reason. I don't need/want to remember the syntax for everything off the top of my head, thats what books and manuals are for. Even when I'm on a project I commit less and less to memory and as much as I can to UML and ER diagram's so I don't go insane taking work home in my head. I code in at least 5 languages and I just remember what I want to do. Personally I find remembering the minutia of every little thing useless until I have to start using it, the cogs grind in my head for a day or so while I clear my memory - then I get to work.
In any case it takes much longer to know the ins and outs of a codebase than it does to remember how to code in a specific language. Companies who ask you to take these tests probably aren't going to be able to supply you with the best resources to do a job anyway. I tried it once and found I was constantly limited to *their* understanding of how the work should be done and my performance was hamstrung by those limitations. I told them that, took my money, left some recommendations and got the hell out of there after a week. Was in a new role less than a week later coding the same language with all the resources I needed to make them and me happy with the results.
My ism, it's full of beliefs.
Do you only date women that fuck on the first date too?
It tends to limit your options with more serious players.
Copying and pasting code amounts to 90% of even the best programmers' jobs.
The best programmers do not cut and paste. They refactor so they only have to do one thing once. If programming is repetitive, you are doing it wrong. Or using Java.
If I were hiring, I would want to give people a test. If I were applying, I would not want to take a test. Here's a better way - have them tell you what a small snippet of code does, and then regardless of what they answer, ask them to rewiite it, or clean it up, or add a feature or something. That shows they can read code, which is important for a new hire. Peer code reviews are not effective if someone can't understand code that someone else wrote. Seeing their rewrite shows you their biases. Do they make a bunch of unnecessary classes? Or to they turn OOP into GW-Basic? Efficient or ridiculous variable names?
The only thing tests show you is who is good at tests. Someone who refuses could simply see the folly of testing someone. I know my first thought is, great now I have to remember something obscure that someone else thinks is important but I have never had the need to memorize. If you do have a test of some sort, you have to realize that a wrong answer doesn't mean they fail - all it does is show that what you expect doesn't match what they know.
And lots of people can learn very quickly. Technology changes quickly, you don't even want someone who knows everything there is to know about Win32 API, because it was replaced with OWL and MFC and JAVA and .NET and Qt/GTK. So you ask your programmer about Win32 and they goof because it's poorly documented to the point that if you don't have Win32.hlp you'll fail almost anything. And most people have template code they use to get started anyway - you don't sit down and write WinMain() from scratch every time. Or at least if you do, you don't deserve a job.
The problem I have with tests stems from the difficulty of knowing what to ask. You don't want to ask simple things that an IDE would auto-complete for you - that's why we have auto-complete. also why we have reference pages bookmarked. Someone's going to argue that you save time when you don't have to look something up. But the large libraries we have today are impossible to memorize, especially the little nuances where you have to remember whether a function returns true for error or false. Much better to check things periodically. I still re-read my assembly language books from time to time, just to remind myself of all the little details that get forgotten.
You don't want to ask an obscure, picky question that someone wouldn't have experience with, and run the risk of running someone off.
When I take a test, it shows me more about the person asking than it shows them about me.
For my last job, I had to interview about 15-20 candidates offshore. I found the most effective technique was to give each of them a 5 question take home test for them to return with answers in 24 hours. If all the answers looked good, followup with a 30 minute phone interview to make sure they didn't just get a friend to do the work. Almost all of the candidates failed the test miserably and thus I didn't have to waste much time with them. Finally, the right guy showed up, did great in the 30 minute followup phone interview and had an offer within a day. When I finally met him in person, he struck me as a humble quiet kinda guy. He probably wouldn't have done well in a traditional phone interview where he had to just sell himself (i.e. oversell himself). But with the take home test, he could objectively prove that he knew what he was doing.
Stuart Eichert
To me testing a persons skills doesn't seem like a problem for a serious interview, especially w/ how people are encouraged to lie on their resumes. Since you are hiring worldwide though I can't see how you would monitor tests for people that could be from anywhere. You could possibly be weeding out those who are unable to pass such test, but you could be weeding out those that don't feel you're company really knows what it's doing. Anyway one of my favorite interview test strategies is one used by my former employee. It was for an entry level QA position at a game company. Essentially this is like sending a High School student to Grad school. For the interview the prospective employee is basically bombarded w/ question, and tests they couldn't of been prepared for, and have no clue how to answer. It's fairly easy to see where people break down under this type of pressure. Most people walk out thinking they've totally lost any chance getting the job, but mostly what the interview was looking at what how they problem solve in a high pressure, and confusing environment.
When I went to work at the NASA Tracking Station in Kauai, HI, I had no idea that the interview included a test in electronics and computing. However after the interview the Facilitator asked me if I wouldn't mind taking a small test to verify my credentials. I said sure and 480 questions later I was finished. This was very thorough and appropriate due the serious nature of spacecraft and astronaut communications. So I'm all for testing when the nature of the job calls for verification of knowledge in the field you are being hired for.
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.
I've written a reasonably large C++ project containing a lot of modern C++ programming techniques, a lot of template magic and what not. You wouldn't look at my code and say I'm not an expert on C++.
Yet if you ask me 'What is a C++ class', I'd be stumped too. How the hell do you answer that kind of question, you expect me to have memorized word for word the definition of a C++ class? Or am I supposed to describe all the properties and rules that apply to a class? How abstract an explanation do you want.
Let me ask you a question; What is life?
- These characters were randomly selected.
11 years of experience and many job interviews? Yea, you're obviously a seasoned professional who is reliable.
Do you seriously think what you said makes you sound impressive? If you walked into an interview with me and said something like that or showed me a resume showing 'a lot' of jobs over 11 years I'd laugh you out of the room.
A lot of interviews is NOT a good thing. You are not special, there are far more people out there who can do your job and do it well who don't think they are king shit. I don't want some douche bag who only has 11 years of experience and can't hold a job for more than 6 months, and neither does practically anyone else.
If an employer thinks they can tell in one visit, they are doing something wrong, hiring you is the first indication.
Let me know when you get a real job, and no McDonalds doesn't count as a real job.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
And nothing of value was lost by not hiring you, thanks for helping them out. Lets see you do that now, with the economy like it is.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I haven't ever interviewed twice either. Maybe I'm aiming low. My needs are modest. When I'm looking for work the first port in a storm will usually do.
Maybe I don't understand this whole interviewing skill, interviewer as a job thing. I've interviewed and hired hundreds of people, and generally speaking if you can do the work and aren't creepy, we're done and you're hired. When I'm interviewing to get a job, if the pay is sufficient and I can do the work, we're done and I'll take it. Later if it turns out the early impression is wrong, we fix it or part ways.
Is it really more complicated than that? Am I oversimplifying things? Interviews don't have anything to do with what people are like or what they are capable of any more than a prom dress reflects your date's taste in fashion. They can't measure a person's dedication, devotion or attention to detail. They can't measure a person's intelligence, though they can quickly rule out the truly dumb, incompetent and spiteful. For this one interview will do.
Help stamp out iliturcy.
As I said before, all I was looking for was a simple 20-second description to show that the interviewee had some idea of how to program in C++, what OO is, etc. Not, "I don't know". Something along the lines of, "uh... it's a thing that has functions and data, which can be private or public so other classes can see them, ..." Is that really that hard?
So if you're such an expert with "template magic", could you say what a template is in 20 seconds? Or would you just say "I don't know"?
The point with a question like this is that there is no one right answer, although there are many wrong ones. If you're proficient in C++ could could answer about the syntax and technical characteristics, or about reusable components comprising state and behaviour, whatever your way of looking at it is. But the key is that you need to already have an established understanding that you can express somehow. (The ability to verbalize abstract concepts may be just as important as technical details).
So to answer your question: life is all the moments between when you're born and when you die. There, that wasn't so hard.
Yep, I agree completely. Usually, when I need to find a new job, I end up going on 5 or so interviews before accepting one job, but both sides can usually tell fairly quickly when the fit is right or wrong (unless HR gets in there at the end with a low-ball offer). I have no idea what's with these freaks on here who think that a normal job interview should take a week or whatever. That might make some sense for a CEO, but not for a regular software developer position.
Geesh, you sound like a total asshole. My longest stint was 7 years. Lots of interviews doesn't equal lots of jobs, it means I'm picky about which jobs I accept. Fuck you.
All this talk of tests is making me shit bricks because I'm a thinker, not a memorizer. That's what books, manuals and the Internet are for. Things like languages, commands, and other bits of info I don't use on a regular basis or that can't be logically deduced have no chance in hell of being remembered by me (MCXX exams are heavy on that sort of thing...ugh). I'd probably fail hard if I was asked to write a VB app 'cuz I'd have forgotten the syntax. It'd only take me a couple of hours to get back into it, but that wouldn't help in the test.
I had an interview at Compuware where they told me I'd be given a test on the second interview where I'd have to write functions and fix bugs on a time limit, but I didn't get called back, probably because I have the interview skills of a rock and I was 17 or so at the time with no prior work experience (although I did meet the requirements IIRC). I was also a bit turned off by that because the testing procedure made it seem that I would've become part of a "software sweatshop" (which comes back to a point you mentioned).
"When information is power, privacy is freedom" - Jah-Wren Ryel
I don't see any problem with being given a test. For me it is an opportunity to really show them my troubleshooting skill, and also gives me an idea of the skill they are looking for. If they give me a test that is extremely plain and simple, then that is what they are looking for, and willing to pay for. If I get a test that requires serious troubleshooting, then they are wanting, and willing to pay for a serious troubleshooter.
Or do what I do. Write it in C. It compiles, it doesn't spit warnings, and it's more likely to work in production by avoiding various object oriented nonsense.
It depends a lot on what exactly you say and do, and what exactly the position and the test are, and how much of all that you explain to your customers.
I know that test situations don't really say much about real-life performance. So if you'd tell me there's a mandatory test where I have to demonstrate how good I am, I'd also say "thanks" and walk, knowing that you're about to hire not the best coder, but the guy with the best "handle test situations" skill.
If it's about verifying that I can do what I claim to do, and you explain to me why and that it's nothing personal, I might point to my references and ask if that's not enough. But I might be willing to do a simple test, one that's obviously only there to weed out the cheaters. Heck, I fill out CAPTCHAs, too.
But a lot depends on how you present it, because it can quickly turn into a "if you don't believe me, what kind of basis for a work relationship is that?" situation.
Assorted stuff I do sometimes: Lemuria.org
Not, "I don't know". Something along the lines of, "uh... it's a thing that has functions and data, which can be private or public so other classes can see them, ..." Is that really that hard?
Cause that's not a proper answer? And more specifically, someone who knows much about something is easier stumped by simple questions as they see all the different ways in which it can be answered.
Templates are a statically compiled generic programming paradigm. Yet that doesn't really say what a template is, so unless I was explicitly told it needed to be a one-liner, I would never use just that answer.
There's a difference between 'I don't know', and 'There's too many answers I could give, which would be the most fitting?'
- These characters were randomly selected.
Seriously, you've either 1) Worked at a large company for so long you really don't know the current interview process (which is not the case given your statements above) or 2) have not worked in a large IT shop.
Even for just contractors, I interview people two or three times. FTEs go through HR first...
Here in Greece we always refuse to take tests, mandatory or optional. It's just not in our culture, and we won't do it even for the best job. The culture here is that you have to accept what we say. It is assumed everyone says the truth, and normally everyone does so.
>Copying and pasting code amounts to 90% of even the best programmers' jobs.
Clearly you wouldn't know one of these best programmers if they bit you.
I've never been convinced by the use of tests - most of them bear no resemblence to how you work in real life, and give you no access to the resources you would have available when you write production code. I wrote up my last set of experiences with job interviews at http://www.ibgames.com/alan/society/interviews1.html
If you going to jump to another company for merely 10% raise, I wouldn't want to hire you.
Don't waste your time unless the new job pays you at least ~35-50% more, you save you time looking for and interviewing for those "more of the same" jobs, and focus on those that really pays.
I am frank about this during interviews (in case I disclosed my previous salary, which I try my best not to). It sends a clear signal to the manager that I intends to stay for long, and I won't be jumping ship unless another job is offering me that much more, so they don't have to worry about me looking for another job right after I get on board. Not sure if it was actually what they thought, but I got hired the last time I interviewed and was asked about it.
Oliver.
Bullshit. If you want the job, you do whatever the employer asks to prove you have the qualifications. Unless you work is universally known, like John Carmack, or Linus Torvalds, you're never too good to take an entrance exam.
However locally, some of us ARE a bit recognised like that. And those who don't recognise you, or haven't seen any of your work, why would you want to work for them when you can continue doing your own thing and collecting the community's recognition?
You want me to work during the interview? You can pay me.
How is taking a test during the interview any more "work" than every other part of the interview ?
One thing employers should do more often is talk about salary up-front, so prospective employees don't waste a lot of time with testing and interviewing just to get an insulting low-ball offer.
But that would be impossible. After all, how is the employer supposed to know what the lowest offer you'll accept is ? :)
In my 20 years of programming experience, as both a consultant and captive employee, most failures proved to be caused by incompetent/incoherent management, a sales force that sold something totally different than what was being built., or a poisoned corporate culture that resulted in a team at each others' throats. If you want to test me, then I think it's only fair that I get to test you. If you want to talk to my last 3 employers, then I should be permitted to talk to the last three employees you terminated. Needless to say, I'm now quite happily self employed.
like google, those idiots over there can't appreciate our genius.
Hire two people at half the salary, and tell them if you can do the job better inside of 30 days than the other, then you get his or her salary. Then you'll see what they can really do.
Thank fuck I've never wasted my time applying for a job working with you.
So a potential employer asks a question and all you can do is argue that the question isn't relevant ? Great way to start a working relationship. How about asking them to redefine the question, or offering as many different definitions as you know about ? Show some willing FFS, you are supposed to be able to solve problems not argue the semantics of the question. Saying either "I don't know" or "there are many different options" does not even attempt to answer the question, it's just being evasive. If you were asked to describe what a class is you go with the most basic definition you can. If they want more they will ask for it. Correctly using terms that are significant, like encapsulation or inheritance in your description hints at a wider understanding of what a class is, and may forestall further questions in that vein. Saying it's where you learned to program is likely to be off-topic. Seriously, have you got a brain, or do you over-analyse everything ?
...
Q. How do I get to the train station ?
A. Well if you start from the city centre you go
Q. But I'm not in the city centre !
A. Oh well you didn't define the question properly, don't waste my time !
Q. ??? {asshole}
Don't you remember, I tried ... but you hadn't washed it for days .... ewwwww .... no way, Jose.
nar
My contract rate is around £63/h + overtime + perks, I am a consultant who "solve problems", "innovates" and "brings the theoretical to reality". This means my ideas are what makes me valuable, rather than my technical ability to actually implement all of my ideas.
I have found that in my interviews they have asked for how I could improve some of their products. I have learned to be very careful when giving these answers primarily because I have not been offered some positions but have seen many of my ideas end up in the real world. Google is infamous for this and I now refuse to go to their interviews for this reason.
I tend to agree that if an interviewer cannot determine that they want me within 2-3 hours in one sitting they have not done their job and have begun to cost my time and money. I have several times been able to put my CV on monster, received a call within an hour, an interview 30 minutes later, and a job offer half an hour later. My skills are unique, if you need me you will know it and save time.
In IT, staffing is a circus. Education, and experience, requirements are entirely arbitrary - different for every employer. IT job titles are meaningless.
If I were to hire a professional, for any sector that is an established profession, I would not have to test that person's technical ability. I do not test the pilot when I get on a plane. I do not test my doctor, dentist, nurse, pharmacist, lawyer, accountant, plumber or whatever.
And that is good thing,because I don't know enough about those technical specialization to administer a appropriate test. And even if I did know enough, would that not be a waste of everybody's time? I could have somebody in my organization test the applicant: but is that person's test fair? Does that person have his/her own agenda? BTW: most employers are absolutely horrible at administering technical exams - and they don't even know how awful they are.
Does it not make much more sense to have stardards? If somebody has been an x-ray technician for the last five years, I have a good idea of that person's training, and experience. If somebody claims to have been a system administrator, I have no idea if that person has any formal education, or what the previous employer considered appropriate duties for sysadmin.
'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.
What about you? Are you looking for a job? What's your resume like? If your CEO is issuing edicts that he hasn't explained, or that perhaps are just arbitrary and seemingly capricious. It may be a tell-tale sign that you may want to look for employment elsewhere.
This is not to say that there aren't real good reasons for making developer searches global. I can definitely think of a few at the top of my head, but if you, as the hiring manager (and as the sole manager in Software Development of your company--it would seem), are not aware of those reasons -- you may want to look for a new better job yourself. After all, software development is difficult as it is, and there are enough real-world constraints to hiring a new developer as it is, being micromanaged by an uninformed CEO may be the last thing that your type of career needs right now.
Why not just walk in and collect a paycheck, don't write a resume, don't interview. From the interviewers point of view, as soon as you refuse to take a test we say to ourselves "caught another one". There are so many unqualified people out there, pushing for a position that they can't handle, a test is a simple tool that I can use to say "prove it." If it was practical to prosecute people who lied on resumes or misrepresented themselves, I believe that would be a good solution too.
While interviewing for my first programming job (in 1987), I was asked to provide, in any language or in pseudocode or flowcharts or any other reasonable form, a process for removing "excess" spaces from a string. "Excess" was clearly defined. I did it both in pseudocode and in C, and I ended up getting the job.
After I got the job, I asked whether I had, in fact, gotten the test correct (I thought that I might have missed some boundary condition). My manager said that I was the first applicant who had actually provided a "correct" solution. They considered it a success if the candidate provided something that showed that he/she understood the problem at all (even if they didn't get boundary cases correct). Even with this "dumbed down" approach, more than half of the candidates failed the test.
Since then, I've interviewed dozens (probably over 100) candidates for various companies, and I still find that the typical candidate couldn't pass a simple coding test such as the one above.
Well, a good interview test isn't about trivia or things you could find in 30 seconds of google. It's things like: What does this code sample print to the screen? Write a regular expression to capture the phone numbers from a file with the following sample data. Write a SQL statement to select all the people from these two tables who have an outstanding balance (ie, can you do a join). That sort of thing.
-- Kate
how deeply they understood object orientated design and the C++ version of that paradigm.
"Oriented" not "oreientated".
Anyone who deeply understands OO would tell you that C++ isn't an OO language, just as Stroustrup admitted when he first presented it. Truth to tell, a C++ "class" is nothing but a Rube Goldberg implementation of typedef.
1) What do you hate the most about the language you love the most?
2) If you had an open-ended budget and a staff of five engineers, what problems would you want to solve once and for all?
3) Describe your approach to QA testing/debugging/performance tuning/regression testing.
4) What professional accomplishments are you most proud of?
5) Tell me about something you invented.
6) Tell me about something that you tried to do and failed, and what you did about it.
The only title of honor that a tyrant can grant is "Enemy of the State."
Anonymous tip: Don't apply at MacAffee or LinkedIn. Been there, walked out of that.
But what if they want you to meet multiple people?
I agree with you. It's difficult to have an absolute rule on anything.
That being said, as a job-hunter it's your job to qualify your opportunities, and maximize the most effective use of your time. In fact, as you're suggesting yourself, doing phone interviews is a great way to minimize the number of on-campus visits. Another way is to qualify the people that are going to interview you. Are those people the actual decision-makers(official or otherwise)? Are those people qualified/knowledgeable about the actual work to be done? In this current economic environment, you'd be surprised by the actual number of hangers-on. People doing the interviews that have no business doing them in the first place.
And, you mustn't forget to qualify the opportunity itself. Do they really need to fill that position right now? Is this is going to be more of a brainstorming session? How much money are they losing every day this position remains unfilled? Is this position really the same one that was originally advertised? Etc.
And obviously, if they expect to waste your time, don't expect them to tell you this in advance. They won't. It's your job to get at this information as soon as possible, preferably through the use of the telephone and some carefully pointed questions, or perhaps through the grape vine, but either way -- try to get at this information long before you invest too much time into that one opportunity. Some opportunities just aren't worth it, or never even materialize.
You gotta admit you do sound like a hard nosed bitch but you have to remember it's not how many chicks you date that makes you a bitch it's how many you say "I love you" to just so they blow you with out following through.
http://www.askoxford.com/asktheexperts/faq/aboutgrammar/oriented
~ roscivs
We do technical interview screening by phone and even then, interviewees sometimes lose their knowledge in a face to face meeting. Either they cannot function in a face to face environment or someone else was at the end of the phone. As a defensive strategy, we have created standard quizzes of 10 simple questions for each knowledge set we require. The questions are very rudimentary and for each subject should take less than 5 minutes to answer without any access to the internet.
Anyone who appears to be what they stated on their resume, we bring back for a demonstration of something they claim to be able to do. Again it's not a challenge more of a confirmation. We use the same non-production questions so that we can compare candidates.
For programmers, we have three programming tasks that we give them. We encourage them to bring in their laptop, any reference books they like, and we provide a connection to the internet. They get two hours and the expectation is that they will not finish all three tasks within that time period. After two hours it is pretty obvious whether a person is creative, organized, and knows what they do and do not know. We've been happy with the process.
For IT folks, we have them set up a linux server. We provide them with a machine with Linux installed and their goal is to set up various services within their two hours. Either they can do it because they've done it many times before, or they cannot. If any specific service is something they have no experience with, and they tell us in advance, we're OK with that. We are confirming that they really do know what they say they know. Again, we've been happy with the process.
Originally we used to pay people for the two hours but the advice we were given by various professional HR experts was to cease confusing the boundary between employee and interviewee.
We do discuss salary in the phone interview. We don't want someone to come in for a face to face and waste our time (and theirs) if the salary we are going to offer is below their expectations.
You must be a real ass.
Take off every 'sig' !!
You appear to like what you describe. To me, it sounds like hell. Enjoy your incarceration.
Requiem for the American Dream
It shows a serious level of immaturity and a severe ego problem to get in a huff about pre-employment screening and tests.
It's not that - most of the objections I see here are people who don't want to do work for free.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
In my former life I was a database programmer so while I was no C or Java wizard I did my best to get the people that understood databases not just someone who would do a SELECT * FROM Table1 and do everything else in the code of their choice.
My favorite question was this
SELECT
FROM
JOIN ON
WHERE
GROUP BY
HAVING
In what steps do you think the database engine would go about the process of solving the SQL statement conceptually and why would the database do it that way? While I would consider the question more technical in nature it does bring out the critical thinking especially those who may not be introduced to it formally through education but understand how a database might react. I could then push the conversation and given difference instances and ask how they might do this and how might the database react. I interviewed and hired folks who got the actual problem wrong but reasonsed and explained enough that I could understand the thinking process they were going through. It was more about how the candidate thinks then what they can regurgitate. As long as any test is exploring the problem-solving nature of the candidate it should fine.
This is not going to be too much help...
When I interview people, my manager usually tells how family friendly the company is, but unfortunately it is a 24/7 business so they expect them to work 6 days a week, no vacations during the season (Sept-February), and absolutely no holidays off (double pay is the law in the country, which is of course honored).
And then there is no decision left to make: the ones who are good look for something else, the rest stay, but then I give them the most simple test I can possibly live with, hoping that they can cope with creating html forms and simple reports with time...
Here is this stored procedure, it gives a simple report, call it from a program and put it in a table on a web page (html). It is sorted on e.g. Agent, Customer. Usually I ask them to send values from a form, and then generate the call from the values for the SP.
When you find a new agent (prevAgent != currAgent), please print a "total" line with totals from the values, when there are no more records print the last agent totals followed by a grand total.....
They are allowed to use anything, but are restricted to a non-visual environment, such as PHP , ASP (Jscript), Perl, or whatever they want and does not generate code from clicking and dragging&dropping...
Even though I set the limits this low for the last interviews (we just needed some help with simple web reports), the results are usually devastating...
Most candidates go as far as putting up the tables fine, but when it comes to the simple task of putting totals or implementing a "hold value" for the Agents, it is catastrophic. Totals at row 0, no totals after the last, totals before the last agent group.......
I do not know what you are recruiting for, but my tip is this: sit them down, pay for the day and see what they do with 4-6 hours of time.
I do not have a problem with a developer entering "php date yesterday" into google. I have a problem with people who copy paste crap they do not understand or those who stick to a visual environment without the basic knowledge to walk through arrays or are stuck at problems without trying to even resource them....
While the 2nd type will pass your test, the 1st type will even refuse it. You might be throwing people out who can program in 3-5 languages, but are scared of being asked language specific questions you would normally use the reference for.
Please post some of the questions, I am really curious...
It's a good idea to ask technical question to probe an applicant's knowledge, however it can be alienating if done wrongly (and I know a few companies who pursue it in a way that is unproductive). What I prefer is to ask applicants in what areas they are most proficient, and then zoom in to find out what they know in the areas. It should not be question-answer style but rather a casual conversation, where you make it clean why you ask what you ask and ideally let the candidate know why the question is relevant to the job he or she is applying for. That way, the applicant gets something back, namely feedback to what degree he or she covers the skills required. While I agree with previous posters that analytical problem solving skills (and also social skills like team ability and communications skills) are ultimately more important than knowledge, I do believe that there are minimal standards that everybody who has reached a certain level of education should accommodate. When you want to hire a developer for a new operating system and they can't name you a few different scheduling algorithms and their main property, those candidates would be ill-advised for hiring. However, don't ask them things that an experienced developer would look up on the Web anyway.
Lifetime position - I could think of nothing worse than tying my future (and potentially self-esteem) to a single soulless company that may get rid of my position because some accountant or posing upper manager said it was necessary. I'd much rather be (and generally am) one of the smart flexible types who can chop and change jobs or long term contracts every year or five, having a more equal relationship to a company, and getting better paid to-boot. Although I understand that in some countries (for various reasons*), this isn't always easy.
* in the US, health insurance would be too much of a risk, and I hear contracting is usually seen negatively there.
* in much of Europe with high social insurance, it's more a cultural aspect, and there are sometimes legal obstacles to long term contracting (where a company may be deemed to be employing you) which must be taken into consideration. But things are changing here slowly.
Oh boo hoo.
Sorry, but an interview like that is a virtual serial gang-rape.
Nope, lifetime position days are over unless you are a fruit fly.
Your looking for someone
Coders
Problem Solvers
Design Geeks
Software Managers
People + Time Managers
Visonary Managers and CEO's
Each of these types of people have to be vetted by someone (who has done the job ? or is likely to oversee the job)
Each of them needs their own kind of motivation and some need supervision.
You get what you get! Some people bull-shit and lie. Others understate their achievements. Some people take credit
from other people's work that they accumulate.
I once interviewed about 14 people for a second level support role MSCE based. Only one person was good enough to answer
my simple questions. One guy had taken one of the highest level MS tests you can take - that morning. I figured that he must be
a little spent so I asked him to ask me one of the questions he had been tested on that morning. He could not think of one or any
other question to ask me. All I was asking was "What does a *.vxd file mean to you?"
Get HR to suggest a combination of people to ask and evaluate - all the suggestions other than tests
seem fine from above. If you must test - test them with your own real-world problem and a theoretical
problem. I guess if they solve the real-world problem and fail the theoretical you have a difficult choice.
Couching a young engineer how to code in C++ was an eye opener. His classmates decided to use a composite
template and he was going to change it a bit - just like the rest. I suggested that all his previous coding
was
A) Internally documented
B) mostly right - time constraint forced some errors into his code.
C) something he could understand as a basis for other C++ work whereas his mates template was mysterious.
I talked him into handing in his own original work. He was then told he had to give a 5 minute talk about
how he coded his problem up.
He did not have working code - one bit was wrong, but he got the third highest mark in the class for his
presentation and code. Lots of things showed up in his Internal comments that made his classmates
shiver.
I like the engineer he will become, I like my engineers to build bridges that meet neatly in the middle
get 99% for calculations (some smaller calculators have no guard digits).
believe it or not, money isn't always the only reason to accept a job.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
On the other hand, there are companies who think that in a recession, people are desperate enough for a job that they'll take anything. Sure, this is true to some extent, but it's still true that if you want top quality talent you're still going to have to pay more for it. Especially if you want them to hang around once things improve.
Actually, there can be if they are collecting unemployment.
What if they were switching jobs because of the working conditions in their previous job? If someone was being forced to work 80 hours a week, I would see switching to a job with the same pay but more sane working hours as a completely reasonable thing to do. Ditto for other things like bad management, benefits, hostile coworkers, and other reasons people might switch jobs.
If you've only been doing this for 11 years and have had "Many" jobs, I'd be weeding you out of the applicants list for being a job hopper.
Ok, that's true, but the new job would have to be offering an absurdly low salary for that to be the case.
4 jobs in 11 years is a "job hopper"?
If you don't want any job hoppers, you might as well just make a policy to hire only people straight out of school, because anyone that's looking for a 2nd, 3rd, ... nth job is most likely a "job hopper".
You're probably one of those PHB managers that wants to pay below-average salary but only wants top-notch candidates, right?
A) Forget about the "different cultures". I mean, I guess you don't want to be drinking, dressed skimpy, or eating a steak or pork so you aren't offending someone, but other than that -- they are working for you, you don't have to be TOO sensitive to their cultural differences. I mean, if I went to Japan to work, I wouldn't expect them to start a US-style office for me to work in.
B) Test away. There are people in the comments who leave as soon as they are tested -- I think they are primadonnas. They may well know their stuff, but I think they would give you trouble at some point soon afterwards. The OTHERs who are refusing a test probably do not know what they claim to, and are hoping you'll back out of the test. joeonsoftware has an excellent article on testing, the short of it is people seem to either have programming aptitude or they don't. He found testing for specific syntax rather arbitrary as opposed to having the person write short code fragments (a poor programmer either won't be able too or will write a horrible algorithm compared to what's possible). Also debugging short code snippets worked well.
This is called "situational testing" and has, from the time of WW2 when it was part of the War Officer Selection Board ("WASB" pron. "Wazbee") process, been shown to be the most effective way of identifying personnel who have the qualities you are looking for. I thoroughly recommend setting typical if not slightly challenging problems and watching the way the candidates solve them. Since team work is usually important, I'd recommend that artificial teams are set up and observed. WASB used to do weekend-long sessions in which simulation exercises were mixed with interviews and yes *sigh* paper tests of the psychological variety.
Those of you who remember those years may smile at an adaptation of my post handle: Ca'ardly Custard.
surely you meant self-respecting.
Would I take a test?
Depends on the job expectations, and my long term goals.
If the jobs is advertised as "software development manager", for example, then I would probably decline.
The job is really a software developer in disguise, and I wouldn't want to sign up for that.
If the job is for "J2EE developer", then I'd be expecting some sort of technical qualification.
This is a sign that the CEO thinks "we only hire the best" It is my experience that places that say this usually hire incompetents and then they have the senior people doing junior level work as the recent moran hires cant' do a thing.
Trust me that's what will happen here if the CEO wants to open up the job search to the entire world.
Part of the problem stems from HR requiring years of experience such as 7 years of xp in vs 2008 (yes I actually saw that) with no idea about transferable skills from different languages or platforms (Solaris is not SCO Unix or Linux in their eyes) etc.
I suppose if you are a manager try to do the hiring yourself without HR doing the AD on Dice.
http://saveie6.com/