Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming Google

Are Brain Teasers Good Hiring Criteria? 672

theodp writes "Your brain teaser prowess may win you a job at Google, but the folks at 37signals don't hire programmers based on puzzles, API quizzes, math riddles, or other parlor tricks. 'The only reliable gauge I've found for future programmer success,' explains 37signals' David Heinemeier Hansson, 'is looking at real code they've written, talking through bigger picture issues, and, if all that is swell, trying them out for size.'" Those of you who have hired employees: have you seen correlation between interview puzzle success and job competency? How should an interviewee best handle these questions?
This discussion has been archived. No new comments can be posted.

Are Brain Teasers Good Hiring Criteria?

Comments Filter:
  • by elrous0 ( 869638 ) * on Friday January 06, 2012 @09:30AM (#38609202)

    If someone is giving you one, they're probably not very intelligent.

    • by dgun ( 1056422 ) on Friday January 06, 2012 @09:36AM (#38609298) Homepage
      I agree. But I would prefer a puzzle to questions like "where do you see yourself in 5 years" and "what are your goals". I want to answer "My goal is to get hired. Why else would I answer such stupid questions?"
      • by jimbolauski ( 882977 ) on Friday January 06, 2012 @09:46AM (#38609408) Journal

        I agree. But I would prefer a puzzle to questions like "where do you see yourself in 5 years" and "what are your goals". I want to answer "My goal is to get hired. Why else would I answer such stupid questions?"

        Those questions are more pertinent to MBA's where your ability to pile on BS in a believable way is an important skill.

        • by Anonymous Coward on Friday January 06, 2012 @09:53AM (#38609526)

          Yet when the people hiring are other programmers or (as in my case) artists, they still feel the need to ask these questions because that's how they THINK they should be interviewing people.

          How do you think I got my job? I BSed my way through their stupid questions and when they finally asked pertinent programming questions I answered intelligently. From what they told me afterwards most people managed to BS the first set and failed on the second.

        • In 5 year?

          I see myself helping bring the company to new heights, utilizing your expert guidance.

          The synergy that already exists between you and I will help us leverage wireless methodologies in order to monetize open-source architectures so that the company can generate e-business functionalities to drive our share prices ever higher.

      • by w_dragon ( 1802458 ) on Friday January 06, 2012 @09:52AM (#38609490)
        The 5 years question is really just asking if you intend to move up the management or technical ladder. If I'm looking for someone who may eventually become a software architect and a candidate tells me they want to be a VP in 5 years I may think twice before hiring them.
        • by JoeMerchant ( 803320 ) on Friday January 06, 2012 @10:05AM (#38609672)

          There's a technical ladder? Anywhere I've ever worked, it's more like a stool - start a decent distance off the floor, then go nowhere.

          • by MagusSlurpy ( 592575 ) on Friday January 06, 2012 @10:08AM (#38609712) Homepage

            Go nowhere? You can always get too excited and knock the stool over!

          • by larry bagina ( 561269 ) on Friday January 06, 2012 @10:23AM (#38609926) Journal
            At least there's not a rope hanging from the ceiling.
          • by mpsmps ( 178373 ) on Friday January 06, 2012 @10:50AM (#38610198)

            Actually, many large companies have parallel engineering and management ladders. The goal of this is to allow your best technical people to advance as individual contributors without moving into management (which they may not be their strength anyway) For example, at my company, Architect and Director have identical HR classifications. Likewise for Fellow and Vice President. If you are not advancing as a technical employee, you should look at yourself, just like if you were not advancing as a manager.

          • by luis_a_espinal ( 1810296 ) on Friday January 06, 2012 @11:20AM (#38610570)

            There's a technical ladder? Anywhere I've ever worked, it's more like a stool - start a decent distance off the floor, then go nowhere.

            That's a function of the size of the company and industry you are in. In general, the technical ladder (or stool) becomes steep very quickly. And as you climb it up, you start to see that you do more management than actual hands-on thingie-building. But do not delude yourself into thinking that this type of management is of a non-technical nature.

            Software Architect. Enterprise Architect. Technical Lead. Principal Engineer. Technical Director. Chief Scientist. Let's call these upper-stool technical positions.

            These types of positions require you to do less hands-on stuff, but the management you will have to do must be technical-oriented. How you assign technical tasks to people and teams will depend on whether tasks are technical feasible, on identifying the technical capabilities of your team, on understanding the resources required to complete technical tasks.

            Granted that a lot of people who get into these positions let go of themselves, gradually detaching themselves from the technical realities on the ground, where the pedal hits the metal. And as a result, their decisions are no longer technical, with technical consequences that is beyond their grasp. But those are examples of doing a bad job in their positions. And that exists at all levels, from the uber-chief of technical reality down to the lowest code monkey.

            These are the fabled paper tigers.

            That is, being detached of technical realities is not an inevitability of working so high up the ladder/stool. Good technical people remain strategically and tactically technical always, regardless of their pecking order. A good above-the-clouds architect can drop back to code with only a few days to clear the mental cobwebs. A good technical foot soldier can extrapolate the reasons behind good high-level technical decisions, even if he/she does not have the management experience (which naturally they don't at their entry level of their careers.)

            My suggestion to people who find themselves staring at the technical stool: put another stool over it, secure it with nails, crazy glue or some other good shit, and then climb it. That is, like a good engineer, you need to engineer and build your technical ladder.

            This can only be done without realizing first that to climb it, you will have to gradually move away from hands-on work without losing your technical wits. You cannot allow yourself to become a paper-tiger.

            This will also means that when you find yourself at a company where there is nowhere else to go but down (because the stool cannot go any higher for whatever reasons), then it is time to go somewhere else where there is a chance to nail/glue another stool over the one you have built so far.

        • by Anonymous Brave Guy ( 457657 ) on Friday January 06, 2012 @10:13AM (#38609780)

          The 5 years question is really just asking if you intend to move up the management or technical ladder.

          Then why not just ask that directly? It might lead to a mutually interesting conversation, and at the very least you're either both going to be more confident in your fit or both going to know immediately that it's not going to work out.

          These are my personal interview red flags for a software developer job, starting with the most likely to result in me throwing the interview/leaving early/declining any offer:

          1. Hiring is based on brain teasers, $-based certifications, or other similarly irrelevant criteria.
          2. Wants to know my current salary. (Bonus point: Doesn't give any indication at the same time of the likely compensation if I'm offered the job. Extra bonus point: Makes clear that the salary range given in the job ad was wildly optimistic.)
          3. Won't show me an example of their production code, real documentation, etc. when given a reasonable opportunity to do so.

          In each case, someone is skirting what matters, instead of finding out as fast as possible whether we are really a good fit and a mutually satisfactory hire might result.

          • by TheGratefulNet ( 143330 ) on Friday January 06, 2012 @12:05PM (#38611090)

            current salary?

            try this: companies are now asking (expecting!) your WHOLE CAREER SALARY TRACK!

            I laugh and refuse. I don't even give current salary, I give a range of what I expect for THIS job.

            one guy even asked if the # I gave for my salary was verifyable. I asked him 'this is a trick question or test question isn't it? there's no legal way you can 'verify' my salary, so who are you trying to kid, here??'

            of course, some actually want COPIES of your pay stub to prove it.

            I walk away from such places. those are big red flags that there will be mgmt trouble later on, at that kind of place.

            look, if you want to hire me, stop playing games. but if you want to start things off poorly, start DEMANDING I tell you private things, like how much I made last year. that's none of your fucking business, mr corporate asshole hiring mgr. talk about rude questions - and the fact that so many people just give in and answer them! astonishing.

            then again, its a horrible time for job seekers right now. they have us by the shorties, as there is NO bargaining and NO unions to help us keep the big co's in check and in their place.

      • by AngryDeuce ( 2205124 ) on Friday January 06, 2012 @09:55AM (#38609556)

        God I always hate those fucking questions. "Why did you chose to apply with us?" Because I need a fucking job! Why else do people apply for a job? Why is that not enough? "Where do you see yourself in five years?" Uh, gainfully employed? Do my life goals really matter to whether or not I can fill this position? What if I saw myself working at the fucking circus in five years, would that have a bearing on whether or not I was hired? Why? "What are your goals?" To make enough money to pay my bills with a little left over for fun once in a while? Is that too mundane?

        Man, I despise interviews. I fantasize about going all Peter Gibbons in Office Space [youtube.com] every time someone asks me one of these stupid, irrelevant questions, but my sense of self-preservation reigns in those crazy ideas.

        • by ShieldW0lf ( 601553 ) on Friday January 06, 2012 @10:05AM (#38609668) Journal

          God I always hate those fucking questions. "Why did you chose to apply with us?" Because I need a fucking job! Why else do people apply for a job? Why is that not enough? "Where do you see yourself in five years?" Uh, gainfully employed? Do my life goals really matter to whether or not I can fill this position? What if I saw myself working at the fucking circus in five years, would that have a bearing on whether or not I was hired? Why? "What are your goals?" To make enough money to pay my bills with a little left over for fun once in a while? Is that too mundane?

          Man, I despise interviews. I fantasize about going all Peter Gibbons in Office Space [youtube.com] every time someone asks me one of these stupid, irrelevant questions, but my sense of self-preservation reigns in those crazy ideas.

          Personally, when someone asks me why I chose to apply with them, I've got a very good reason. When someone asks me "Where do you see yourself in 5 years", I tell them the truth, and then I ask them what they will do to help me get there. If they answer wrong, I walk. And when they ask me to engage in meaningless work so they can judge me, I tell them they're welcome to judge my portfolio, but if they want me to start problem solving, the meaningless of the task is irrelevant... they're still going to have to pay for it.

          You can weed out most bad employers in this way. Not all of them, but most. It helps if you have 3 months salary in reserve for emergencies like you should so you don't end up entering a bad situation out of desperation.

          • by Apocryphos ( 1222870 ) on Friday January 06, 2012 @10:17AM (#38609842)
            You can also weed out many good employers this way. The HR process is just the door to get in at a lot of places, the working environment is usually a totally different beast.

            If you did what you describe when applying to the company I work for, you would not be considered for employment. And even though I may disagree with some of our candidate selection processes, we tend to hire great people and the work environment / compensation / benefits are awesome.
          • by delinear ( 991444 ) on Friday January 06, 2012 @10:19AM (#38609874)

            It helps if you have 3 months salary in reserve for emergencies like you should so you don't end up entering a bad situation out of desperation.

            This is the best advice out there. If you enter any job interview from a position of needing the job rather than wanting it, you risk not being happy in your role. And don't be afraid to turn the question back around - if someone is asking you where you see yourself in five years, why are they asking that? Is it because they want someone who will grow with the company, do they have a specific path mapped out that they'd want you to follow, are they hoping for someone who will stick in the one position forever, etc - ask them, if you got the job, where they'd see your role in five years, because it depends more on them than you at the end of the day (it doesn't matter if you see yourself as CEO if they only see you in a junior role).

          • It helps if you have 3 months salary in reserve for emergencies like you should so you don't end up entering a bad situation out of desperation.

            3 months isn't really sufficient these days. You really need to be thinking more along the lines of at least a year or 2.

            I know this from experience: I went from having 6 months of reserves to having to take a job that put me in a really bad situation for a while - their basic M.O. was to hire desperate people, work them like crazy for a few months, and then fire them before the benefits kicked in (at a rate of at least 1 person every 2 weeks). I accepted that position for 1 reason: It was better than starv

            • I would so fuck over any company that put me into that position.

              I could do 10 man years of damage in the few months they kept me.

          • And when they ask me to engage in meaningless work so they can judge me, I tell them they're welcome to judge my portfolio, but if they want me to start problem solving, the meaningless of the task is irrelevant... they're still going to have to pay for it.

            So, you refuse to answer the one question that correctly evaluate your technical habilities? How do you expect the employer to discover if you are good or not? Most of the times a portifolio just isn't good enough.

        • Re: (Score:3, Insightful)

          by Anonymous Coward

          I ask those questions, and it is exactly to weed out people like you (and in fact the answers have actually made me say no to candidates in the past).

          I have a passion for what I do and in my experience, the best people for jobs where I work are ones who share that passion. We already have people who treat it as a 9-5 job and pretty much all of them are "ok". The ones who stand out are ones who think of it as more than just a job to pay their bills. If you intend to work just to get by, that is all you will

          • I've come a cross a very good counter-example. The best programmer I've ever encountered, after nearly 20 years in the business, is a guy who barely gives a crap about the job. For whatever reason he's extremely productive. It's probably some combination of good work habits and strong intelligence and good education (bachelors from MIT in Comp Sci.)

          • Oh, obviously I never actually answer that way, and I know how to bullshit with the best of them, so I generally fare pretty well in interviews. The bullshitting gets extremely tiring, though. For once in my life I would like to just allow my body of work, and the praises of my former employers, speak for itself.

            In my experiences, the places that most harp on "being a part of a family" and "a passionate work force" and all that other crap are exactly the opposite when actually employed there. Many times

        • by asliarun ( 636603 ) on Friday January 06, 2012 @10:28AM (#38609994)

          God I always hate those fucking questions. "Why did you chose to apply with us?" Because I need a fucking job! Why else do people apply for a job? Why is that not enough?

          If you repeat the question to yourself again, you'll see that the question is about why you are applying to that *particular* company, not why you need a job. Are you truly interested in what the company does and what practice area it is involved in, or as you say, are you applying only because "you need the fucking job". This helps the company determine if you are just going to be a pencil pusher clocking your time and going to be a sourpuss about it, or if you are going to kick some ass in your job.

          "Where do you see yourself in five years?" Uh, gainfully employed? Do my life goals really matter to whether or not I can fill this position? What if I saw myself working at the fucking circus in five years, would that have a bearing on whether or not I was hired? Why? "What are your goals?" To make enough money to pay my bills with a little left over for fun once in a while? Is that too mundane?

          I would imagine that just about *any* company would be interested in you want to do with your career and how the position will fit not just your current needs (bring food on the table as per your statement) but also your future needs as a person AND as a professional. Are you seriously tell me that you are an automaton - you just want to clock in your 8 hrs at work so you get your paycheck and aspire absolutely nothing else from your career??

          Why would you react so strongly to an interviewer who is trying to understand your career aspirations? Its not like they are asking you how you lead your life or how you floss your teeth, the question is only about your career goals. Sooner or later, you will end up discussing this with your manager anyway.

          • If you repeat the question to yourself again, you'll see that the question is about why you are applying to that *particular* company, not why you need a job. Are you truly interested in what the company does and what practice area it is involved in, or as you say, are you applying only because "you need the fucking job". This helps the company determine if you are just going to be a pencil pusher clocking your time and going to be a sourpuss about it, or if you are going to kick some ass in your job.

            You'

        • by Splab ( 574204 ) on Friday January 06, 2012 @10:32AM (#38610036)

          If you don't have a specific reason for going for *that* company, you wont get the job. You *MUST* show that you have spend at least some time in researching what they do and why you think it would suit you to work there. There are perhaps a hundred people applying for that job, you need to make you look better than the others.
          What I want in 5 years? What I would really like, a boat in the Med, an Audi R8 and enough money to live like a spoiled brat - in fact I'd love to live like that right now. On a more realistic outlook I'd like for x,y,z etc. E.g. manager position, advanced field stuff, travelling whatever.
          But if you can't answer it and show you've thought about it they will almost always pass.

          To be frank, these questions are "designed" to vet people like you. My gut feeling just from reading your post is you wont fit in - and that is your biggest problem; it's not about being the worlds best at whatever you do, if you can't sell yourself you might be the next Bohr, but still not get a chance at proving yourself.

          Oh and for all the puzzle/whiteboard programming haters out there. I was once tasked with doing a hashmap on the whiteboard as part of an interview. Instant thought was "Fuck!? who would ever remember those fuckers?"; but I went to the blackboard outlined most of the map and when it came to the actual hashing algorithm I told them that I had no idea how to do that, but knew what book to look in. Afterwards they offered me the job and specifially complemented me on how I handled the whiteboard task.
          If you get asked to do a puzzle or whiteboard test, do it, get it over with - yes you might not have access to your favorite cheat sheet, but thats life. Sometime you might end up in a room full of clients and act like you are on top of the problem even though you have absolutely no clue what just went boom. It's all about selling yourself and showing you can handle pressure.

          • If you get asked to do a puzzle or whiteboard test, do it, get it over with - yes you might not have access to your favorite cheat sheet, but thats life.

            That's not even remotely close to why I despise whiteboard tests. They indicate poor interviewing skills on the company's part because they have no relation whatsoever to my future job duties.

            The last time I wrote on a whiteboard in a real-life setting, I was standing in front of my elementary school classmates to work through long division problems. I never wrote on a whiteboard in college. I have never, not once written on a whiteboard at work. I do not anticipate that I'll ever be shoved into a room full

            • by maple_shaft ( 1046302 ) on Friday January 06, 2012 @12:35PM (#38611478)

              Wow, you really hate whiteboarding don't you? I am so completely the opposite of you that I must respect your opinion because I can't relate to it at all.

              Whiteboarding conveys a few things, a high level of spatial intelligence required for diagramming and modeling complex problems visually. It also is an accessory to communication about a complex design or process that a group of colleagues or lay people wish to know more about. If a candidate is whiteboarding a process for me and he silently doodles on the board then that is a problem. You are supposed to talk through the problem primarily and cement your ideas in on the board so that everybody can see a visual summary of your explanation.

              The fact that you despise it means that you completely fail to understand why somebody wants an engineer who can whiteboard. It is a sign of an individual who can communicate and discuss problems on multiple facets, while somebody who just wants to demonstrate skill by typing in a text editor tells me that this person doesn't care about communicating or discussing complex ideas, they just want to showcase their skill.

              You may be extremely productive writing software or some such engineering activity, but you seem like an extremely low-level task oriented person and that is not what most companies want. We want critical thinkers who engage in higher level design, thought, and communication. They don't want cowboy coders. They don't want a lone wolf.

        • by ifiwereasculptor ( 1870574 ) on Friday January 06, 2012 @02:23PM (#38612994)

          "Where do you see yourself in five years?"

          This is a particularly fun question to answer. My suggestion is that you grab a nearby sheet of paper and start calculating right away, so after weird two minutes during which the interviewer will be pretty confused, you can say something like "well, exactly five years from now will be a saturday, and at precisely this time on saturdays I'm usually at the supermarket. Considering my shopping routine and the time I usually get there, I'll probably be at the frozen foods section. Leap years have already been factored. Now if your question wasn't really that specific and you only wanted a general idea, I can redo the math by adopting a standard year as a sequence of 360 days."

          Full disclosure: I'm unemployed.

      • by Frohboy ( 78614 ) on Friday January 06, 2012 @10:09AM (#38609734)

        I agree. But I would prefer a puzzle to questions like "where do you see yourself in 5 years" and "what are your goals". I want to answer "My goal is to get hired. Why else would I answer such stupid questions?"

        I believe Mitch Hedberg said that to "Where do you see yourself in 5 years?" in an interview, he replied, "Celebrating the fifth anniversary of you asking me that question!"

      • Re: (Score:3, Interesting)

        by Boona ( 1795684 )

        As a person who is involved in hiring, we just want to get a sense of whether the position is right for you or whether you'll just flake out because you rather be doing something else. For example maybe in 5 years you expect to be a manager or a team leader but we don't expect openings. Or the opposite, maybe we do expect an opening and we are looking for someone with aspirations to become management so we can groom them for that position. Personally I like to see candidates achieve their objectives in our

    • by ILongForDarkness ( 1134931 ) on Friday January 06, 2012 @09:40AM (#38609342)
      Perhaps. The article says "looking at real code" is better. Again perhaps. For example the problem there is: did they really write the code, if so how long did it take? Did someone else suggest fixes etc? You don't know. I mean 300 lines of beautiful C is all fine and dandy but if it took you 3 months to write it and half of it is cut and pasted from the web how good is it really?

      What brain teasers hopefully do is take a problem close to the types of things you see in the job. Even though it is all programming different companies either due to industry or existing infrastructure/policies tend to have different types of coding "puzzles" that come up again and again. Hopefully this test problem is one you haven't seen before and they get to see how you approach something you don't already know how to solve, how close to a good design do you get on the first interation, if they point out a problem how you go about fixing it etc. All real world important stuff to know about someone.

      • by ehack ( 115197 )

        Last time I looked, average programmer productivity was rated at -counterintuitively- 10 lines per day, so 300 lines of PRODUCTION GRADE C code would be a very good contribution for 3 months. And in fact cut and paste of well- tested code that gets the job done would definitely be a BETTER thing than the self-invented wheel your average 14 year old kid would write.

      • by Whorhay ( 1319089 ) on Friday January 06, 2012 @09:55AM (#38609538)

        Is using code snippets from the internet really an issue? Is there a good reason to re-invent the wheel, pulley, block and tackle, lever, wrench, lightbulb and whatnot every time?

        Time constraints could certainly be a problem if it takes longer for someone to lookup a solution and implement it than if they just come up with the solution themselves and implement it. And there are legal issues with copying large chunks of code, but I wouldn't think that banning it wholesale is a very productive way to go.

      • by Splab ( 574204 ) on Friday January 06, 2012 @10:44AM (#38610152)

        My problem with "own" code is I have none. Sure I have the stuff I did back at the University, but thats 5 years ago - I never program outside the job, which means anything I've done belongs to someone else; in fact, I don't even own a computer these days.

        (Also note that if I did in fact program outside working hours, it would most likely still belong to the company, so again, I'd have nothing to show).

    • by leonbloy ( 812294 ) on Friday January 06, 2012 @09:45AM (#38609394)
      In my experience: They're a moderately good indicator of a special kind of intelligence; which is not a very useful indicator in the typical hiring process.

      Puzzles help to distinguish programmers from lawyers. Not to discriminate good programmers from bad programmers.

      • Deciphering decades if not hundreds or years of legal precedent and laws and then coming up with a line that will persuade the jury or judge isn't a puzzle.
    • by asliarun ( 636603 ) on Friday January 06, 2012 @09:59AM (#38609594)

      If someone is giving you one, they're probably not very intelligent.

      I completely disagree, or at least, your statement is so broad it is untrue.

      Brain teasers are just like any other interviewing tool - what matters is how you use the tool.
      As an interviewer, if you use brain teasers to determine *how* the candidate is attempting to solve the problem, you are probably doing it right.
      If you are using the brain teaser to tick a box in your checklist based on the answer, you're probably doing it wrong.

      The really neat thing about brain teasers or puzzles or the bizarre questions you sometimes encounter like "How many pigeons are there is Manhattan" is that they are a very good way to judge someone's unstructured problem solving ability. How someone approaches this kind of a problem is a good proxy for their ability to debug hard technical issues or their problem solving ability in general.

      Making a statement like "hire a programmer based on their programming ability" is also an obvious statement to make, apart from being a bit grandiose (look at us , we are cool because we are contrarians and we swim against the tide). The reason why many interviewers resort to other techniques is two fold - one, lack of time or other constraints that prevent the interviewer from directly testing a programmer's programming ability, and secondly, judge the non-programming aspects of the candidate like how they react to an ill-defined problem or a fuzzy situation, how well they will get along with others, how much of a self-starter they are etc.

      Or, if I put it another way, if you are not hiring a programmer on the, to quote, "code they have written", what are you doing, hiring candidates on their baking skills? I get what 37signals is saying and all this got messed up to begin with when HR took over the interviewing process from programmers (especially in large companies). However, the other statements that are flying around about how *any* non-programming related question is stupid is also frankly, over the top.

      • Judging someone based on the code they've written could, potentially, get you (or the person giving you that code) in legal trouble. Some companies would not want me giving out the code I've written for them. It's technically not my code to be handing out to a potential competitor. Sure, you could cherry pick some generic methods out, but those could just as easily be cherry picked from a forum.

      • by SecurityGuy ( 217807 ) on Friday January 06, 2012 @10:44AM (#38610148)

        The really neat thing about brain teasers or puzzles or the bizarre questions you sometimes encounter like "How many pigeons are there is Manhattan" is that they are a very good way to judge someone's unstructured problem solving ability. How someone approaches this kind of a problem is a good proxy for their ability to debug hard technical issues or their problem solving ability in general.

        This is really not true. My response to questions like that improved dramatically when I read an article that explained questions way out of left field like that are intended to test your problem solving ability, so do your best to estimate an answer and explain your thought process. Reading that article didn't make me better at debugging hard technical issues, but made me dramatically better at handling off-the-wall interview questions nimbly. You're not measuring what you think you're measuring.

    • by JoeMerchant ( 803320 ) on Friday January 06, 2012 @10:04AM (#38609658)

      If you're hiring a sales guy, your interview should test his persistence, resilience, likability, and perhaps ability to hold his liquor.

      If you're hiring a customer service rep, your interview should test their patience, politeness, and thoroughness at collecting information.

      If you're hiring an engineer, solving puzzles is part of the job, brain teasers are one quick way to gauge how a potential hire will respond to the kind of task the job requires.

      As for hiring HR staff, I'm not really sure how to judge them, other than the fact that any good person I've ever encountered in HR didn't stay in the job for long.

  • by alphatel ( 1450715 ) * on Friday January 06, 2012 @09:33AM (#38609256)
    Two employers offer you jobs. One asks you a teaser and expects a solution but lies, the other asks for experience and references and expects performance but tells the truth.

    What do you ask the parrot that lies about the job the truthful parrot is offering?
    • Re:Test (Score:5, Funny)

      by sakdoctor ( 1087155 ) on Friday January 06, 2012 @09:42AM (#38609362) Homepage

      Two applicants apply for a job. One loves teasers and would happily work for the company forever for low pay but lies, and the other will flip out and murder you with corporate stationary and always tells the truth.

      What do you ask the water cooler that can only glug once for yes and twice for no about the applicants?

      • Re:Test (Score:5, Interesting)

        by hoggoth ( 414195 ) on Friday January 06, 2012 @11:21AM (#38610594) Journal

        Interviewer: You're in a desert, walking along in the sand, when all of a sudden you look down...
        Applicant: What one?
        Interviewer: What?
        Applicant: What desert?
        Interviewer: It doesn't make any difference what desert, it's completely hypothetical.
        Applicant: But, how come I'd be there?
        Interviewer: Maybe you're fed up. Maybe you want to be by yourself. Who knows? You look down and see a tortoise. It's crawling toward you...
        Applicant: Tortoise? What's that?
        Interviewer: You know what a turtle is?
        Applicant: Of course!
        Interviewer: Same thing.
        Applicant: I've never seen a turtle... But I understand what you mean.
        Interviewer: You reach down and you flip the tortoise over on its back.
        Applicant: Do you make up these questions? Or do they write 'em down for you?
        Interviewer: The tortoise lays on its back, its belly baking in the hot sun, beating its legs trying to turn itself over, but it can't. Not without your help. But you're not helping.
        Applicant: What do you mean, I'm not helping?
        Interviewer: I mean: you're not helping! Why is that?
        Interviewer: They're just questions, Leon. In answer to your query, they're written down for me. It's a test, designed to provoke an emotional response... Shall we continue?

        • I preferred Vala's response:

          Vala: "Question 2: You are in the desert. You see a tortoise lying on his back in the hot sun. You recognise his plight, but do nothing to help. Why?" Hmmm...why? Because you are also a tortoise.
  • by Nidi62 ( 1525137 ) on Friday January 06, 2012 @09:34AM (#38609276)
    Bring the puzzles as an applicant to the interview, and ask the interviewer to take them. If the company puts someone who isn't even smart enough to do brain teasers in a position as important as interviewing and hiring, then the upper management probably isn't very intelligent either.
    • Yeah...cuz I'm gonna take my smartest employees and put them in HR...

      • by w_dragon ( 1802458 ) on Friday January 06, 2012 @09:54AM (#38609536)
        HR shouldn't be interviewing for technical positions beyond a basic initial interview to ensure that the candidate actually exists and wants to work for the company.
      • No, but I might put a technical person on the interview panel. They don't even have to ask any questions; Just be there to gauge the responses, maybe answer questions the applicant may have (and gauge the nature of those questions). Even if they have no sway on the hiring policy, they may demonstrate that the employer cares enough about who they hire to get a technical view of the applicants. That in itself shows that your potential boss won't be a PHB, even if that's who you're interviewed by.
  • by Mannfred ( 2543170 ) <mannfred@gmail.com> on Friday January 06, 2012 @09:39AM (#38609332)
    Every organisation has different needs, but even so "looking at real code they've written, talking through bigger picture issues" takes time, and an initial interview with more basic questions should probably be there to weed out the weakest candidates (unless the people in charge of recruitment interviews have nothing else to do and want to look busy, of course).
  • by WOOFYGOOFY ( 1334993 ) on Friday January 06, 2012 @09:39AM (#38609336)
    I had a hedge fund ask me a physics puzzler problem for a job as a Java developer.

    Needless to say unless you spend time puzzling over this specific type of problem you don't have the skills to answer them.

    The impression I had was they were going through a dog and pony show of "trying to find a candidate" for their position. I am not sure what they were up to. Whatever it was, they weren't looking for a candidate for the advertised position.

    There was an absolute reek of duplicity, insincerity and dishonesty about every single employee I met on that interview, starting with the prostitute-cum-receptionist who greeted me to the project manager who wouldn't look me in the eye to the interviewer who looked over my resume (which had only a distant physics class) and said "we're not going to ask you about programming, I can see you've got that down, we want you to solve some puzzles" and sprang on me some physics puzzles I could only solve if I were a physics major.

    I couldn't wait to get out of there.

    I saw that ad for a few more months online. I always wondered what they were up to.

    • by Anonymous Coward on Friday January 06, 2012 @09:48AM (#38609450)

      I work as a quant in the hedge fund industry and use puzzles in the reverse way described here to weed out physics and math/finance majors that can't program well enough. I give them a programming puzzle (rather than a physics or math puzzle) and grade their performance. I am usually not hiring these people for their programming skills but I cannot afford having a math whiz that requires support from professional programmers in order to be productive. The most productive quants in my industry are the ones who are also programming whizzes.

  • by wisnoskij ( 1206448 ) on Friday January 06, 2012 @09:39AM (#38609338) Homepage

    Brain Teasers definitely test something.
    If for example you are applying to a brain teaser solving/creation company then it would be ridiculous not to have to solve a few to get in.
    If you are using one to test mental flexibility, well that can be as useful as being able to churn out well made and documented code, for the appropriate job.

  • The brainteasers are there to see if someone is smart. Could the employee escape from a paper bag if necessary? I'd say these puzzles are important for finding creative problem solving and would be just as useful if not more useful in a manufacturing/fabrication/maker type of job.

    Think of that American drilling team that drilled the hole to free the Chilean miners. That engineer's rig wasn't meant to do what he did with it. Can't aim it? He aimed it with a hack. Hole's plugged? Fixed it with a hack? Don't have a 28" drill head for this rig? Let's hack one together in a week. If that guy with the big brain didn't pick up the phone and say "hey"...those 33 guys would probably have been entombed for half a year if not forever.

    Dude did it in one month with a toolbox full of hacks. Fucking brilliant.

    • by jythie ( 914043 ) on Friday January 06, 2012 @09:50AM (#38609466)
      The problem with brain teasers is they do not test if someone is smart or if they will be able to hack a situation.. they test how well the subject metathinks the test creator. They are artificial situations where the test creator has thought of both a problem and solution, and really only tests if the subject is good at figuring out how the test writer's mind works. It is kinda like reading a mystery novel... you are not solving a mystery, you are solving a writer's thought pattern.
  • by ircmaxell ( 1117387 ) on Friday January 06, 2012 @09:44AM (#38609390) Homepage
    I actually wrote a blog post on this very subject this morning (I pushed up the publishing when I saw this). The post [ircmaxell.com]

    In short, I disagree. I find brain teasers invaluable. But not in determining skill, but in determining personality and how a candidate behaves when they are faced with a challenge that they aren't familiar with...
    • by dubbreak ( 623656 ) on Friday January 06, 2012 @10:19AM (#38609880)

      I find brain teasers invaluable. But not in determining skill, but in determining personality and how a candidate behaves when they are faced with a challenge that they aren't familiar with...

      Exactly. At my last job when interviewing candidates with coworker (software team would hire other team members, a practice I thought worked well) we would use:

      • -a simple programming question (basically do an intersection OR bag intersection on two lists), to make sure they could code
      • -a brain teaser (logic / simple circuit), which we'd ask programmers, not just EEs
      • -"hypothetical" situation dealing with management push for releasing code before QA is complete

      All the questions had value.

      • -The programming was best used with co-op students, to weed out those who can't code. It did weed out a few FTE candidates that had "over a decade of coding experience".
      • -We didn't expect all candidates to answer the teaser, in fact it was chosen as it would be difficult to solve. We would allow a fixed amount of time to solve it, and would give more time if the candidate was keen on solving it. The point was to see how they would do under duress. Help would be given as time went on, to see how they would handle new information regarding the problem. If a candidate gives up immediately and asks for the answer... well in my experience (since we were forced to hire one anyhow), that's what they'll do on the job, "This is too hard, I can't do this." If they turn all red and get flustered.. they might not do so well under stress. One of our best cadidates, who worked out excellent on the job, kept calm, was methodical, asked questions to clarify.. they handled themselves perfectly. That's exactly how they behaved after the interview on the job.
      • -The "hypothetical" question checked their personality and how they deal with confrontation. This is probably the most important aspect as people who are decent technically can be trained and learn new skills etc, while people who are poor communicators and don't deal well with debate or conflict most likely won't be able to pick up those skills quickly.

      On a team personality match is a huge aspect. Questions should bring that out (such as "shooting the shit" during an interview to put the person at ease, e.g. after a teaser). Of course that means the interview must be performed by at least one member of the team. Generally we'd have a pair interview and if the candidate went further they'd meet the rest of the team (rather than a panel grilling them). It doesn't matter if the candidate is super coder who can code at 80wpm if they can't communicate and are at odds with the rest of the team. Those type of resources can be useful if you can apply them correctly, however a good candidate that can work well with the team (in my experience) is a lot more valuable than an excellent developer that needs to work solo.

  • by doconnor ( 134648 ) on Friday January 06, 2012 @09:48AM (#38609438) Homepage

    I've never liked Brain Teasers. Every time I try one I keep thinking about how I would write a program to solve it.

    • If you're interviewing for a programming job, would you really want to work somewhere where that's a disqualifying answer?

  • by brucmack ( 572780 ) on Friday January 06, 2012 @09:48AM (#38609440)

    I guess we combine the two approaches: we send our candidates small coding problems to solve. So we see real code they create and have a standardized way of comparing it to what other candidates have provided.

    It works really well at filtering out people we don't want to waste time talking to, and gives us a starting point for the technical interview. It isn't useful for deciding whether or not a candidate should be hired, since there are many other factors that come into play.

  • by nightgeometry ( 661444 ) on Friday January 06, 2012 @09:53AM (#38609512) Journal
    But the idea isn't to get an answer - and I am very up front that I don't care about the answer, and I already know it anyway. What I do want to see is how someone approaches a problem that they don't know how to solve. I had one candidate ask me the answer, I already know it after all - immediately top of my hiring list, and she was an awesome hire. Another asked if they could use google on their phone - again a pretty much perfect answer. The puzzle is completely irrelevant, the ability to question, put forward ideas and not just say 'I don't know' or, even worse, go completely silent and get embarrassed that you don't know, is pretty fucking critical. IMHO.

    I also look at samples of previous work, and we make all candidates carry out real world tasks along side us.
  • by Diss Champ ( 934796 ) on Friday January 06, 2012 @09:53AM (#38609520)

    I've been at my job 10 years now, and if I interviewed for it or a similar one now would expect (and do well at) a detailed technical interview. But it is in a very different area than what I studied in school- when I was being interviewed, we all knew that what the interviewers needed to discover was whether I could learn what I needed quickly and then apply it to designing new things. They already knew I didn't know it yet. I didn't even know Verilog (I do the digital side of mixed signal chips).

    The best question was a quick lesson in how one of the main building blocks of many of our systems works, followed by questions about implications and what would happen if various broad changes were made with the architecture.

    But the puzzle questions (usually requiring broad math and science knowledge, no one asked me elephant in the fridge type questions) were a good way to get at whether I had a broad knowledge base and could apply it to new things.

    So they have their place, probably more for people crossing fields than those doing something they are experienced with.

  • by wandazulu ( 265281 ) on Friday January 06, 2012 @10:01AM (#38609626)

    To quote Bob Fosse: I don't want people who want to dance; I want people who *need* to dance. That is what I look for during an interview, someone who clearly loves what they do and doesn't just sit around waiting for orders or just did whatever was told of them. I typically ask them about a project they were on, and if they get into the details, even if it's not exactly specific to programming but that they understand the "big picture", as well as their role in it, and look to see the eyes light up. It's especially Then I move on to the question that a lot of people don't expect, surprisingly, but is very telling: "What got you into programming?" Any flavor of "because it's really really cool" works; sadly a lot of responses are "it was either this or becoming a lawyer | dentist | whatever".

  • Sort of (Score:4, Interesting)

    by Megane ( 129182 ) on Friday January 06, 2012 @10:07AM (#38609696)

    If you're using brain teasers as pass-fail criteria, then you're stupid. And if you're using them in an interview process that lasts less than an hour or two, you're even more stupid. They can be good for understanding a person's thought process during problem solving, but that's it. It's not the answer, but how they come up with it. That being said, the "how many gas stations in such-and-such city" where you have to pull estimates out of your ass are not good for choosing programmers, so don't even go there.

    I used to work for a big company that you've probably heard of. When we interviewed people, our group had a brain teaser that we liked to use, probably because the answer (and there was a fixed, definite answer) was not the obvious one. And we got to draw pictures of it on the white board while asking it. But it was the programming test that really mattered to our group.

    First of all, we had them do it on a white board in front of the group. (This was after all the individual interviews were done, and we had warmed up the group part of the interview with a brain teaser or two.) We weren't looking for getting API parameters in the right order, just that you could do the algorithm on the fly, and in a less than quiet environment. (typical cubicle farm level noise from us chatting to each other during this) We didn't even care what language they wanted to write in, the point was getting the algorithm right. And if they got something wrong, we would tell them how the output would be wrong, and let them fix it. Again, the goal was to see how they write code, and show us how, not that they could spit out the right thing from memory.

    First was to implement strcpy. Any C programmer (our stuff was mostly C++) should at least understand how strings and pointers work to build something around *p++ = *s++ with a loop. So you probably got an off-by-one error, so what, we point it out, you fix it, but you at least got the basic idea right if you got even that far. Second was to write code to copy a file, since you should also be able to understand how to get data in and out of files. Then we would ask how to make the file copy faster, since most people would try the one-byte-at-a-time approach, and you ought to know about buffering, too. Finally, reverse a singly-linked list. This is something that any CS student should learn in their second year Data Structures class. Not to memorize it (because it's kind of pointless to memorize such a function), but to figure out how to do it from scratch. If your degree says "Computer Science" on it, you should be familiar enough with how to walk down linked lists to at least make a decent start on this one.

    Well, guess what. The fresh out of college CS grads generally failed horribly, especially the ones that had been weaned on Java, where you don't have to deal with pointers like you do with C and C++. It was really stunning and even sad to see people fail at this. (The EE grads did much better, FWIW.)

  • by fzammett ( 255288 ) on Friday January 06, 2012 @10:09AM (#38609742) Homepage

    Ive been on both sides of the table plenty and have both faced and given brain teasers. To say they are inherently good or bad hiring criteria is thinking of it the wrong way. Its just one tool in the toolbox. A hammer isnt inherently good or bad, you use it when its appropriate and not otherwise.

    I personally put little stock in them, except that I love to get a wiseass answer because it shows personality. For example, I got hit with the Google-ish "how many golfballs fit in a schoolbus?" question once. My answer, almost immediate, was: "Come on, thats just silly, everyone knows golfballs do not ride the bus when they go to school... they don't need to, they're balls, they just roll!" The interviewer absolutely loved that answer.

    To me, there's far better ways to evaluate a candidate. For a programming job its actually easy: give them a real-world task typical of the position, tell them they have as much time as they need, set them up at a workstation, show them where the bathroom and snack machine is and give them some space. See what they produce in that situation.

  • by NReitzel ( 77941 ) on Friday January 06, 2012 @10:22AM (#38609920) Homepage

    Over 30 years of hiring programming staff, what I have found is the converse of your proposition.

    People who are not good at solving brain teasers are poor at being good programmers. If they are good at solving brain teasers, that really doesn't say anything about whether or not they will be effective as programmers.

    Also, I'd be remiss if I didn't add a few words about "being effective." It's not ability to produce code that counts, it's ability to produce code that can be maintained later by other, less effective programmers. A good solid foundation is absolutely necessary, as is sufficient commentary so that someone who is stone cold on the code can dig into it and fix things, or change parameters. The long term cost of code is not creation of code, it is maintenance of code.

    Looking at code is an important hiring criterion, but it is also something that is simply and totally out of the ability of an HR person to achieve. Perhaps the idea of using brain teasers is simply because it is a screening process that can be carried out by HR.

  • Funny anecdote (Score:5, Interesting)

    by loufoque ( 1400831 ) on Friday January 06, 2012 @12:08PM (#38611124)

    I once applied as a programmer to work on a server infrastructure for a next-generation search engine. They were looking in particular for people with great expertise in the C++ language and in the Boost libraries, areas in which I was a very good candidate.
    They asked me to perform a task and send the result by email before meeting me in person.

    The task was to write a program that would take an integer n, and display the nth integer that satisfies a particular condition involving primes (I have forgotten what the exact condition was). I was told I would be judged on the performance on my program.

    It was obvious that what they wanted was for me to know the mathematics about primes so that I would know the right formulae to compute the nth value quickly. As I didn't know them, it was irrelevant to the job I was applying for, and I didn't want to spend time researching it on the Internet, I chose to fit their requirements differently.

    I computed all the values beforehand, and simply made the program return the nth value of a table. Technically, it fitted the specifications they had given me exactly, and was the fastest solution possible.
    Yet they chose not to make me go to the next stage.

    Looks like brain teasers don't like being beaten at their own game...

    (Another funny thing about this event is that I sent the code to the person as a tarball, and he was unable to open it and asked me to send him a zip instead.)

The truth of a proposition has nothing to do with its credibility. And vice versa.

Working...