Slashdot Mirror
Are Brain Teasers Good Hiring Criteria?
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?
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.
I actually wrote a blog post on this very subject this morning (I pushed up the publishing when I saw this). The post
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...
If a man isn't willing to take some risk for his opinions, either his opinions are no good or he's no good
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.
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.
The best is the enemy of the good
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.
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 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.
-1 Uncomfortable Truth
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.
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.
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.
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?
- For the complete works of Shakespeare: cat
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.)