Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Businesses Technology

Pre-Employment Skill Set and Aptitude Tests? 106

stumbler asks: "I just had a lengthy conversation with my boss and co-workers about the value of giving skill set tests (programming ability) and aptitude tests (like reasoning or logical ability) to technical employees before they are hired. (We currently have no such tests.) For those that work in companies that require pre-employment tests, have you seen an impact in the quality of technical employees hired?"
This discussion has been archived. No new comments can be posted.

Pre-Employment Skill Set and Aptitude Tests?

Comments Filter:
  • no value (Score:3, Insightful)

    by maddu ( 522722 ) on Friday May 28, 2004 @10:43PM (#9282917)
    They hired me. Which means the skill set tests don't have value! Any standard test can be gamed.
  • Derive quadratic theorem (don't just spit it out!). Prove square root of two is irrational. If I remember, those who past generally were well liked by the others who interviewed them.
    • by mrgrey ( 319015 ) on Friday May 28, 2004 @11:01PM (#9282987) Homepage Journal
      If I remember, those who past generally were well liked by the others who interviewed them.

      Then there's the grammar test....
    • and you run a math teachers office right?

      to most of us that type of stuff isn't very useful.. sure alot of us have done it at some stage (high school) but what bearing does asking such questions actually have on how well i can do my totally unrelated work...

      if perhaps you were asking simple algorithmic questions... maybe boolean algebra simplification then i could see some benefit..
    • Before we can hire you to write UI widgets in Java, please derive the quadratic theorem. NOT! For some jobs this makes sense. For others it's nothing more than a thinly veiled elitism.

      I was taught how to derive the quadratic theorem in my freshman year in high school. Unfortunately, it was only a one hour lecture, and the knowledge was never, ever used again in the subsequent twenty five years. I don't think I could pass your test. But fortunately, I don't have any bosses stupid enough to make it a job req
    • I theorize that the number zero does not exist, therefore, I must stop typing now.
    • Derive quadratic theorem

      The first thing I would say to you is 'what quadratic theorem'? There is a quadratic formula, but no such thing as a quadratic theorem.

  • by Anonymous Coward
    we give the subject a relatively simple question with no real answer that they should be able to analyze and generate opinions of on their own. Then we check the browser history and see how they posed it in Ask Slashdot. If they didn't provide any insight or guide the conversation in any way, then that's generally bad :-)
  • at my current job... (Score:2, Interesting)

    by glen604 ( 750214 )
    I was given math and logic tests as part of the interviewing process. Where they relevant? Somewhat. Did they really separate the good interviewees from the not so good? I doubt it. I'm guessing that any distinction they reveal would have come up anyway in the interview process.

    Perhaps the reason I got hired by the company was not necessarily my performance on the tests, but when I told them later on in the interview that (truthfully) I had enjoyed taking the tests, and liked solving logic puzzles i
  • at my work (Score:3, Interesting)

    by way2trivial ( 601132 ) on Friday May 28, 2004 @11:13PM (#9283034) Homepage Journal
    a hotel.. we have one test for desk clerks.
    our tax rate is 6%. anyone who cannot answer, what's the tax amount on a 100$ sale, we will never hire..

    answers vary, one accounting major looking for a summer job answered "about 60$" and called the next day to apologize, needless to say, he wasn't hired...

    a simple test can be the most effective....

    • Re:at my work (Score:5, Interesting)

      by Sad Loser ( 625938 ) * on Saturday May 29, 2004 @03:11AM (#9283820)
      I am a hospital doctor, and we only hire doctors who have either come from hospitals we know (and can trust)
      OR
      we give them a short set of multi-choice questions, and see a few patients with them.

      We find that the quantitative test (MCQ) separates out the complete no-hopers (like your test, but probably a bit more reliable as there are 50 questions), and that the qualitative test (watching them work) helps differentiate the good candidates.
    • the hardest part isn't separating the skilled from the no-hopers (which should be mostly recognizable from the C.V. and interview), its finding those who'll actually do productive work

      I worked one summer as a roadie for a live-rock-and-roll production company, and the majority of the interview had to do with skills like knot-tying, cable coiling, equipment identification in a sea of red herrings in a short period of time, that kind of thing, which of course tells you who can do the work and who can't. how
  • I work advising on travel arrangements - a form of travel agent, except I'm not selling anything. My employer used to test numeracy and geography, which is clearly applicable to the job.

    The geography test was basically a national map with dots on it and a list of place names, including several fairly obscure ones. If you scored less than 75% you didn't get the job.

    My employer no longer tests these things. This has resulted in a lower grade of new-starter, but if they're intelligent they learn, and if they
  • see subject
  • because the damn PHB hired the ones that failed anyway.
  • I've done some applying for positions at various software houses throughout north america and while I am still in univeristy, alot of their responses have been constructive. The general idea is a test for an overall skill set like programming languages and development cycles, and a test or two in the logic and reasoning ability. Just to make sure that you are not a talking box, and you have a brain that can deal with a changing enviroment.

    I am presently working a 4 - 8 strech in tech support as a co-op ter
  • You can have someone submit an impeccable resume, or be able to answer questions quickly and reliably on tests, but the only way you'll ever truly know the ability of someone is to see how well they work.

    I've conducted a few interviews where I poked and prodded to determine ability, but that one hour is rarely enough. You can always find someone who can talk a great game, but in the end cannot produce (or cannot produce to expectations)

    In the end, I think the best result is to offer said individual an
  • by Anonymous Coward
    ....give them a series of printed c/c++ code (or relevant language used in the company) that has obvious and less obvious errors / bugs in it. Tell them to locate the bug and find a work-around. Measure the time that it takes them to do so. Have them fully explain the bug and tell you where they've found it before (past programming experiences). this is a very good measure.
    • Give them a computer to do it on too.

      After all, if they forget a semicolon, they're not going to print out their code and read it in order to fix it.

      Tim
      • by KDan ( 90353 ) on Saturday May 29, 2004 @04:27AM (#9283996) Homepage
        That's a good idea actually. Put them in front of whatever IDE you use (whether they've used it before or not) with a program that has compilation errors, style errors, obvious bugs, a couple of subtler bugs and one very subtle bug.

        Then tell them to make this code work, and see what they do. That will give you a pretty accurate idea of several things:

        1) How quick-thinking they are - I know people who have "the skills" but apply them oh-so-slowly they're a frustration for their co-workers. Watching them code is like watching paint dry. Unsurprisingly they're also slow in other parts of day-to-day worklife interaction.
        2) How they react to a frustrating problem - debugging someone else's code can be very frustrating. You can probably weed out the guys who get really annoyed and fretting... they'll probably end up pulling a heart attack on you during a stressful phase of the project! (note: that is actually discrimination based on health so you will get sued if you don't hire someone based on that. So don't do it, ok?)
        3) How good they are at debugging. Having talented debuggers is useful on any project...

        Sounds like a brilliant test to me... maybe because I would have passed it very nicely :-P

        Daniel
    • Tell them to locate the bug and find a work-around.

      I think this is silly. The skills you really want in a programmer are the ability to keep up to date in new technologies, write clean code (that doesn't have weird bugs in te first place) and have a good idea of how to structure a program so that is easy to maintain. In fact, a really good programmer may well be poor at unravelling bugs because he has little experience in debugging - his code doesn't need a lot of debugging.

    • Hopefully the interviewer will test his code first. I had a guy write out a very simle function in C++ and ask me what it did. I described its function and he said I was wrong, so we went over it line by line. It turns out that he didn't know how the integer divide worked well enough. He didn't own up to his mistake, but at least he agreed that if it worked the way I told him that I was right. (Sorry, but I don't remember the problem, but I understand how C arithmetic works - I helped develop a C compi
  • by Plasmic ( 26063 ) on Saturday May 29, 2004 @12:21AM (#9283255)
    Pre-employment tests are sometimes good for generic categorization of employees. Skills and aptitude tests are quite different from cognitive and behavioral tests. If you've ever taken either of the latter, they can be laughable. The problem is that hiring managers give those tests to a candidate, see "Inability to focus" and "Cannot develop strong relationships" on the results, and assume that's bad.

    Give the same tests to your current employees and try to correlate the results. You'll undoubtably find a few patterns amongst your excellent employees that differ from your mediocre employees. The more results you collect from candidates that you know are horrible along with your employees, the better you'll be able to customize the feedback for your exact environment.

    In a previous job, I found that all of our core software developers did fantastically on a general cognitive test (IQ-like), but that most did horribly on behavioral tests -- they were all "Likely to be insecure with their work". In fact, potential candidates that were also "Likely to be insecure" often matched the personality profile that worked in our group. So, test your own employees and see what happens if you highlight candidates that perform similarly to those employees that excel, rather than taking the simplistic approach of "a bad score must be bad!" with prospective employees.

    You may find that if you give a variety of tests to 20 candidates, ranging from specific skillset assessment to leadership profiles, that you can at least take a harder look at the 3-5 candidates that score poorly across the board -- if they're barely above average (or worse) and they don't test well, that's not a great sign. Conversely, you could hire someone because they do a great job on all of the tests, but that would be equally horrible -- lots of people are good at taking tests and bad at producing actual work.

    Assuming a handful of people with equal qualifications, why take the risk? Especially in this job market, there are too many people out there that not only have the right skills and behavior that can also do well on the corresponding tests.
    • How exactly do you get current employees to take IQ and personality tests (and share the results with management!) without pissing them off?
      • Tell them exactly what you're doing, and tell them that it's optional. Perhaps provide a bonus for doing so. Tell them they'll get people in to their department who are more like them, and thus more likely to work efficiently (like they obviously do). Don't tell them if you've already sorted them in to good or bad employees though. Obviously :)

        I wouldn't mind taking the tests. Especially if they were to give me percentage values (how I relate in various traits to the average population, the average of
  • Comment removed based on user account deletion
    • You expect the prospective employee to believe you when you tell him about the benefits, his opportunities for advancement, what kind of work he will do, etc., don't you? How would you feel if he demanded that you prove all of those things before continuing with the interview?

      Usually those things are all in writing, in the offer letter.
      • Yes, but there's no way to actually prove the company is going to do what it says it's going to do. In fact, the only way to guaruntee the words mentioned in the contract you sign is to quit, and possibly, though unlikely, by recovering damages after the fact. You can't even be 100% positive that you'll be paid -- even though you have it on paper.

        Doesn't sound a whole lot different than hiring an employee. Eventually, you have to put your faith in that person or company and assume what they are telling

      • Comment removed based on user account deletion
    • Employment agents don't know shit when it comes to IT so they should give some sort of test to see if you're actually bullshitting. Also, employment agents tend to "tidy up" resumes a little so that you fit the job description.
  • by ClosedSource ( 238333 ) on Saturday May 29, 2004 @12:58AM (#9283352)
    Interview problem solving often has something in common with Adventure style games: Guessing what the author was thinking is more effective then solving the problem.

    When was the last time you solved a real-world problem in a few minutes with someone looking over your shoulder who already knew the "correct" answer?

    There is no reliable algorithm or heuristic for hiring the best people, but some companies are comforted by introducing pseudo-rigor into the process.
  • I am only 16 so I dont have much work experience, but it would seem to make sense that you bring a portfollio of past work (on a USB thumb drive, CD, etc) and they look at it to decide if they like your style, how well written it is, etc. I am sure you all know what a portfollio is so I wont elaborate much more, but it would seem like the best idea to me.
    • That would be ideal, but typically when you work for a company, your source code belongs to them, and they may be very adverse to you taking it with you. They will be even more adverse to you taking it with you so that you can show other people.

      Can you imagine being a Windows developer and taking some of the code with you to fill your portolio? "Here's some 10,000 lines of random Windows code. No, you can't really be sure that it's the source to Windows. No, it won't really run on its own. No, you ca

    • I too would think that a portfolio of past work would demonstrate to a prospective employer that I can engineer software. I have published thousands of lines of Java and C++ code on my web site www.bearcave.com [bearcave.com].

      What constantly strikes me as odd is that people I've interviewed with are more or less unwilling to look at my work (note that this work belongs to me and has been done on my own time). And those who do interviews that consists largely of programming problems [bearcave.com] still insist in having me code

  • Frankly, it depends on the job.

    For programming? It's great. In java, you should be able to explain polymorphism, for example, or how to prevent memory leaks even with garbage collection, etc.

    This is opposed to an interview, where you can ask more off the wall questions. A test is really only a bar - do you have the basic knowledge or are you bluffing? The interview will select the good people.
    • "or how to prevent memory leaks even with garbage collection"

      Ignoring the bad grammar, what sort of answer are you expecting here? I can't think of any answer for this off the top of my head... Is it just to remember to delete objects when you are finished with them, or am I missing something?

      • Is it just to remember to delete objects when you are finished with them, or am I missing something?

        You are definitely missing a whole heck of a lot.

        Problems with memory leaks in Java are the result of setting up conditions in your program that make the garbage collector think that an object never goes out of use. A typical example is a stack used by an object that persists over the life of the application that keeps growing as the application runs. Objects with references on the stack are never GC'ed be
        • That's just so dumb that it wouldn't even occur to me as a 'memory leak' so to speak.

          And I know it's a sort of 'begging the question' statement, but that's what I meant by "remember to delete objects when you are finished with them".

          I was thinking that perhaps there are certain conditions where it fails. Like how reference GC's fail with circular references.



          • It's not a memory leak, per se. Java doesn't have what's commonoy known as memory leaks. More appropriate would be the term "memory loitering". No object is ever put in a state where it cannot be gc'ed - only where they will not be gc'ed.

          • Like how reference GC's fail with circular references.

            Java doesn't have that problem.

            There is only one case I know of when Java GC fails, and it's pretty rare. If you create a 32 bit primitive int that has the same value as the address of an object, the GC won't delete the object. It's pretty rare for that to happen, and has been fixed in Hotspot.

  • to prospective Software Engineers. I'd never seen that practice before, but it actually works out quite well. It quickly weeds out those who don't really have a clue about programming. Everybody pads their resume to some degree or another, so it helps to determine who truly knows their stuff from people who merely recant the latest buzzwords. We use three primary languages here: C, C++, and Java. Depending on the position/group a candidate is being interviewed for, the applicant is given a set of 5 simple
  • I'm a sysadmin by trade, and I think a nice way to do it would be to give them a broken system to diagnose and fix. Hardware or software. Whatever you have that needs fixed. It shows you how they handle the type of stuff you need handled. And, if you have enough applicants, you never have to hire anyone! Just have them fix your stuff for free! ;)
    • My typical attitude as an interviewee, when asked if I know how to do 'X', and I don't know off the top of my head - is to say "give me google and/or manual pages and I will be able to figure it out."

      However, after discovering a new online "hacking" challenge [try2hack.nl], I've started thinking that in some situations - appropriate on-the-spot challenges might be worth doing (note: my field is comp security, so this example is appropriate). Such examples would give the interview candidate an opportunity to demonstrate

  • Misdirection (Score:1, Interesting)

    by ColaMan ( 37550 )
    Give them a wrong address for the company.
    Nothing too misleading , such as a different town, just be a few streets out.

    People who then show up at your office are obviously good at solving simple technical problems.

    People who make it to the interview on time get bonus points.

    For fun, give them some paperwork to fill out at the end of the interview and say "I just have to duck out and check on something - back in a tick".
    Leave and time how long it takes for them to wander out of the office in search of so
    • For fun, give them some paperwork to fill out at the end of the interview and say "I just have to duck out and check on something - back in a tick".
      Leave and time how long it takes for them to wander out of the office in search of someone... 15 minutes to half an hour's a pretty good baseline.


      A similar test is to keep the person waiting in the lobby for a long time and have the secretary observe him...how impatient he gets. A bad temper will easily be revealed if the person has to sit and wait for just 10
    • Oh great. (Score:3, Insightful)

      If you would do that to me I would not consider taking employment with you.

      To me it would look like you are disorganized and frankly could not care to work with a company with such messy outlook.

      • by ColaMan ( 37550 )
        Well, good for you :-)

        To me, that would look like you are somewhat inflexible and unable to cope with last-minute changes or pressure.
        And the fact that you are unwilling to wait it out for something that your interviewer has to deal with that might *just* possibly be more important than your interview suggests that you value yourself a little too highly ;-) Of course, the polite thing to do would have your interviewer come back after a minute or so and explain the situation.

        Anyhow, the comments I have mad
    • Re:Misdirection (Score:4, Insightful)

      by travail_jgd ( 80602 ) on Saturday May 29, 2004 @10:30AM (#9284775)
      "Give them a wrong address for the company. Nothing too misleading , such as a different town, just be a few streets out."

      It cuts both ways though. If I was applying to a company that hired people incapable of giving the correct address, I'd think twice. Likewise, if a company deliberately misled me as part of the interview process, it would be harder to believe anything else they said.

      And the most you've done is prescreened people who can use Mapquest. Whoop-DEE-doo.

      "For fun, give them some paperwork to fill out at the end of the interview and say "I just have to duck out and check on something - back in a tick". Leave and time how long it takes for them to wander out of the office in search of someone... 15 minutes to half an hour's a pretty good baseline."

      Most of the interviews I've been to have had a specified time limit (or have been happy to tell me when asked). A lot of people don't have time to waste on interviews: they're either taking time away from their current job, or have the day off. Why waste their time "for fun"? Wasting 15-30 minutes of interview time is stupid when you could be doing something productive (like talking to them).
    • Well I scout out my interviews one or two days before hand. That way I kow where it is, where to park, how long it takes. All this proves is that I plan ahead.
    • I'm confused. Are you testing patience (will they wait for 15-30 minutes once they're done with their paperwork) or initiative (they only stay for 15-30 minutes, then they *do* something)?
    • A similar thing happened to me - I accepted an interview for a startup in London - they gave me the registered business address, not the actual interview address. As a consequence I ended up having my PDA stolen while trying to find the correct address. I mentioned this at the interview, and they just thought that was funny.

      They may have been desparate for staff, and willing to pay any price, but with that attitude, I had no interest in working for them.
  • It verifies resumes (Score:3, Interesting)

    by Danny Rathjens ( 8471 ) <slashdot2.rathjens@org> on Saturday May 29, 2004 @06:00AM (#9284160)
    You'd be amazed at how many people will claim they know a language but be unable to implement 'hello world' in it; or claim to use linux as a workstation yet can not say what their favorite window manager is. I don't even think it is necessary to know the language you will be working in since a good programmer can pick up a new language rather quickly if they are well educated and/or grounded in a few languages. But if you claim to know it, you'd better know it.

    I guess I have an abnormal hatred of dishonesty, but I think the best use of these tests is too weed out the flat out liars or those that 'bend the truth' a bit too much regarding their skills.

    So, my point is simply that, yes, these types of tests are quite useful for verifying resumes, but not a whole lot else.

    • by Anonymous Coward
      This is one of the more idiotic posts I've seen recently, in that it tries to make what the author thinks is an obvious point, but gets it so wrong.

      If you look into any C++ book from a few years ago, you'll see ways of coding hello world that will not compile on a modern setup. There are plenty of smart coders around today that know C++ very well, but who have worked on an environment that protects them from language instability, and might get tripped up by library issues on a hello world on a new platform
      • I see your point, although you could have worded it in a much more civil tone. I actually started a paragraph to say that being too picky that people don't know exactly what you think they should is an easy trap to fall into. I erased it since my post was getting long.

        I was also over simplifying by saying 'write hello world'. Our real skills test doesn't even have that. It has 3 to 4 questions in each category. I would only consider you to have "overstated" knowledge of one of those categories if you a

    • It is definatly good to weed out those who are either exagerating or just not good judges of their own skills.

      Of course, HR departments brought some of the exaggerations on themselves by requiring cantidates to have X years experiance in X-3 year old technologies. That's closely related to HR departments that get the actual requirements, then throw in a few shiny objects that will NEVER be needed.

      Applicant should have 12+ years experiance in Java and C++, MS degree or better. Position: help desk, $10/ho

  • Backfires... (Score:2, Interesting)

    by Anonymous Coward
    Over the past few months I have hear stories about the recruiting practices for a certain Bay Area company. They use multiple tests - what they have ended up with is a tech manager and a bunch of programmers who are comsumed by the minutae of the programming language they use and their own intelligence. The project that is the basis for their company has not made much progress and they are burning money.

    Presumably, they will be smugly certain that it was something outside of the brain trust that caused the
    • ...what they have ended up with is a tech manager and a bunch of programmers who are comsumed by the minutae of the programming language...

      Thank you!! I was trying to think of the right phrase to describe the complete worthlessness of these tests. I try to educate my own company about the pointlessness of these tests and I am having some success. I try to recommend alternative questions that uncover a candidate's true experiences. Questions like, "tell me about a difficult technical problem you faced and
  • I am a director for a small, niche ISV. I use a skillset test to guage how quickly someone new can be productive. What I find more important is the verbal questions that I give in the interview. I find out how long they have been in a certian technology then I ask questions to determine how deep they are in it. We pass on those that take a long time to learn a new technology.

  • Back in the day is was just the IPAT, now it is online! [ipat-o.net] It is an Information Processing Aptitude Test. Different organizations in the company have differing opinions about the test. I think that doing well on it helped me get hired.
  • I'd give them a bs list of tasks in excel (I work in finance) and the test would be if you use the keyboard for them or the mouse. People who use the keyboard in spreadsheets for things like cell navigation, copy paste and other repetative tasks. Perhaps you could do the same with a command line vs GUI, I don't know if this is quite the same, as excell (the productivity increases by an order of magnitude if you understand the ctrl seeks and 5 basic keyboard shortcuts (cut, copy, paste, fill down, and fill

Anyone can make an omelet with eggs. The trick is to make one with none.

Working...