Slashdot Mirror
How Should You Interview a Programmer?
phamlen asks: "Having hired several programmers who haven't worked out, I'm wondering if other people have better success with interviewing techniques. Usually we have a two 'technical interviews' and a final interview. The technical interviews tend to be a combination of specific technical questions ('Is friendship inherited? How would you find out?') and algorithmic ('Given the numbers from 1-10 missing one number, how do you find the missing number?'). In addition, we essentially try to interview for: intelligence/performance. technical skills (algorithmic, etc.), and team compatibility. Unfortunately, we've been burned a couple of times by people whose performance didn't measure up to what we expected from the interviews. So I'm wondering if other people wanted to share their interviewing tricks - how do you find out if someone is a good programmer?" Surprisingly enough, we've done a series of these, so if you are interested in similar questions for sysadmins,
network engineers, or the one who will follow in your footsteps, then we've got it covered. We've also covered core IT questions as well. What special ways do you have of evaluating potential coders? How well have they worked out?
Unfortunately, I don't have the answer... I tend to look for someone with general problem solving skills, intelligence, and a genuine passion for that they do.
if you are asking them actual questions that have definite single answers - what is to stop them from studying for it?
wouldn't you rather have someone that can think on their feet rather than those that heard from a friend what your interview was like and studied to do well for that interview?
There are some odd things afoot now, in the Villa Straylight.
Ask them a few riddles. For example,
the ones discussed here
My other first post is car post.
You cannot go wrong, when you either only hire people you know or hire people, that are recommended by someone you know to be a worthy developer. If you don't get enough people this way, you can always ask the candidate if there is someone who can recommend them.
Remember, the worse he looks, the smarter he is.
Finally, math books without any of that base 6 crap in them.
Ask them if they write code as a hobby
What Open Source projects have they contributed to?
Ask them to bring some samples of source code they've written, and then do a walk-through
Ask them to solve a simple exercise with pseudo-code, then explain which language they would choose to implement it and why
Get them to find a known bug in some code that matches your "house style" (describe the unintended behavior)
Talk to their previous associates and boss....
YMMV....
Paul Gillingwater
MBA, CISSP, CISM
It seems that we have a collection of these articles and comments in our little community. CmdrTaco, why not put together a new section with a theme of Technical Recruitment.
Perhaps this new section could include these helpful questions and resources following the current re-education and recruitment techniques of the industry.
Any thoughts?
"Here's a piece of paper. Write me a program that does ."
I actually had a guy do this to me. I'm a very good programmer, but I don't keep syntax of every language I've ever used in my head, that's what REFERENCE BOOKS are for.
Find someone who understands logic, flow, analysis, etc. and is also good with people and you will have found yourself an excellent programmer. Getting hung up on syntax memorization is retarded.
"I'm just here to regulate funkiness."
The technical interviews tend to be a combination of specific technical questions ('Is friendship inherited? How would you find out?') and algorithmic ('Given the numbers from 1-10 missing one number, how do you find the missing number?'). In addition, we essentially try to interview for: intelligence/performance. technical skills (algorithmic, etc.), and team compatibility.
"Is friendship inherited?" is just a bad interview question. Are you looking for specific programming languge knowledge, or the knowledge to search for answers? "How would you find out?" indicates the latter. Phrase the question accordingly: "If you wanted to brush up on friend classes, where would you turn?"
Depending upon the skill set you're seeking, algorthimic questions should be of an appropriate level of difficulty. "Given 1-10, with one missing..." is a question my mother could answer without any knowledge of computer science. If you want to check for algorithmic understanding, pose a graph problem. They're easy to visualize and easy to describe. You should get some stock answers like Dijkstra's or BFS or Kruskal's... Then ask for the person's own algorithm to see how he reasons through the problem and modifies his approach. This helps test for intelligence and flexibility in thinking.
As for testing team skills, pose both hypothetical questions and real-life questions. "What would you do if a person in your team was not pulling his weight in a project?" "Describe a time in your life when teamwork was essential. What were some problems you encountered?"
In general, the best thing you can do is force the person to talk. Not just simple, short technical answers, but stories and long "essay" answers. You shouldn't ask specific details about C++ ("In a switch() statement, how you specify the default case?") but general questions ("When would you use a switch() statement?"). Of course, you would want to ask harder questions, but you get the idea.
The best interview I had was with the CIA (Central Intelligence Agency). Did they care about my technical skills? No. They had my resume and my transcript. Every question got me talking about myself. "Tell me about a time you failed" separates the men from the boys. And you get a good sense of who this person is... which is the goal you're really seeking.
seek honesty not perfection.
Ask questions of humility. That should be a good indication. Honest people will have no trouble telling you of their past mistakes and faults as well as their strengths and abilities.
If someone only tells you all the good they've done [e.g. positive outcomes] then they are either a miracle or holding things back.
Tom
Someday, I'll have a real sig.
I've been on both sides of the interview table, and from what I can tell, most interviewers fall into the same trap: focusing too much on detailed technical questions. In reality, your programmers are going to be involved in much more than writing eloquent solutions to programming problems. Your programmers will most likely be involved in project management, project design, project implementation, project testing, and project deployment. Be sure not to get wrapped up in asking too many questions like "how many bytes in a java int?" Instead, look for good all around problem solvers. Ask about their design experience and what tools or resources they have used in designing previous projects. Ask how they would handle testing when a project has been under-quoted. These are questions that good problem solvers will be able to answer quickly, and those who "studied" for an interview will not. It will give you a much better idea of how your potential employee would work out in your business. Be sure that your interviewee will not only be a good programmer now, but also in the future when your development tools change.
Another useful tool for an employee interview is to have a break for lunch with a group of your staff. This will give you and your staff a chance to meet the interviewee in a less structured environment. Many times, an interviewee will relax a bit during your lunch, and you get a much better idea of the person's attitude. Someone who answers technical questions very well may turn out to be a social dunce. Or you may find that the person doesn't share the goals of your company. It will also give your staff a chance to find out if they fit in with the group.
If you don't feel satisfied without asking some technical questions, be sure to ask questions which apply to your framework, and not necessarily the programming language you use to implement that framework. For instance, if you design using Object Oriented principles, ask about "has a" and "is a" relationships. The idea is to ask questions that are still relevant if you change languages from C++ to Java or to some other language.
Using some of these ideas, my company has been able to easily pick the good candidates from the poor ones. YMMV: good luck!
I agree with this post.
Having been on both sides of too many interviews, the best process I have seen is Art & Logics. They require applicants to write a short program using a class they provide. The first "test" of the interview is to see the applicant's response to the class not compiling. If the person write HR asking for a working version, the process is terminated. Besides getting a feel for the applicant's nature, the fix requires a knowledge of the c++ preprocessor. After getting past that hurdle, the applicant is free to design/code the program as they see fit. (They are required to follow certain coding standards). Once submitted, it is reviewed by senior programmers. Those that have done a nice job are then provided an in person interview. By this time, the employer already knows quite a bit about the applicant. As one who hates technical interviews (ie: Microsoft's), I actually enjoyed Art & Logic's. It provided a non-threatening environment that allowed for creativity while being able to learn about my technical abilities. See: www.artlogic.com
Ask questions that allow you to ask "why".
For example: 'Given the following scenario blah, blah, blah, what type of data structure/class would you use?"
When they answer with Tree/Hash etc. Ask them why they picked that answer. Ask for the logic behind the decision. Most people in the field have either read enough/heard enough in school to scam their way through multiple guess, yes/no type questions. But its hard to fake your way through good thought processes. For every "reason" they give, you also have another option to say "why" or "what about an alternative"...In general the "whys" are more important than the "hows".
Ask what the person does with their home computer.
If they don't use a home computer for anything useful (i.e. more then email/games) its much less likely that they enjoy their work than one who uses their computer for other things. Do they write code of ANY kind at home? Do they tinker with the hardware. Do they run *Nix or something else other than Windows?
Ask what they do for fun. Someone with no social life may be productive but will probably cause you other problems because they wont play well with others. They'll be an outcast (i.e. no communication) or they'll just creep people out so that no one wants to deal with them.
How many people have you rejected that would have turned out to be the best people in your company?
I'll bet the answer is well over 'one.'
You're looking for a magic bullet. A simple mechanical reduction of human issues. It doesn't exist.
The only sure fire way I've ever found of evaluating an employee is to give them something to do and see how it works out, bearing in mind that often times a person with mediocre skills turns out to be a very valuable employee and those with great 'creds' often turns out to be nearly worthless. That's why God invented the probationary period.
To get a better look at what I'm driving at here take a look at another flip side. *You* are asking this question because you are performing less than 'perfectly' at evaluating prospective employees. Why? Because you're humans. You yourself are too complex to easily reduce your performance to a repeatable, mechanical formula.
It is always, ultimately, no matter what interview and evaluation process you impliment, going to come down to what it has always going to come down to, an educated guess and a gut 'feel.'
And you'll make mistakes, you'll hire people you shouldn't have, and *you'll let go people you should have kept.*
Thus it has always been, thus it will always be, as long as it's people we're dealing with.
KFG
that you're interviewing programmers, aka code monkeys. They might dance, but they will never perform. You'd probably like an engineer or a scientist. How you interview for them is totally different.
I worked for a startup company back when it was the cool thing to do. The nerds with titles were debating how to interview for a new position, and the battle came down to this essential problem - which is the best question:
1. What is java.lang.Thread.join()?
or
2. Tell me about how you start and stop different execution paths in a multithreaded application.
If you ask (1), you get a code monkey. He or she will write good code when given proper instruction because he or she has a minimum set of skills. Code monkeys can handle hammers and screwdrivers because they've used them before. Ask them to use, say, a quarter sheet finishing sander and they will be confused.
Ask (2), and you get an engineer or a scientist. Knowing that you can wait for the termination of a thread in java with join() is nice, but understanding the implications and uses of join() is ten thousand times more important. Understanding the concept is more important than perfect syntax.
My suggestions for questions are these two, because I think you are less likely to pick a code monkey and more likely to pick an engineer:
1. Tell me about a project you are particularly proud of, and explain some of the technical issues you faced in finishing it. (This is a good question for several reasons. First, you get a good sense of interpersonal skills, because they have to tell a story. You also can gadge a candidate's general interests in the larger field of computer engineering/science, and a feel for their particular strengths. Lastly, you get to see whether this candidate is a finisher or a ship-it-when-it-compiles person because you asked about finishing a project, which is never the most glamorous, but frequently the most important part of being a software engineer.)
2. Tell me about a project you worked on with a team. What kinds of challenges did you face and how did you solve them? (Again, story telling, this time with a definite bend towards interpersonal skills. You also get to assess team work skills, etc., in a technical environment. When I was asked about this question I talked about how my junior design project team needed to be more organized to meet our project schedule, so we got stricter about version control, documentation, etc. If the candidate tells you story about this irritating person or that jerk, you should consider whether or not you're going to be the jerk he talks about in his next interview.)
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
1] Describe the technical accomplishment you're most proud of.
2] How did it work?
3] What did you do on it?
4] At our company, we have this general problem X. What are your first thoughts on how to solve it?
5] How would you rate yourself in (language)?
6] A language specific question. For instance in C, what does "volatile" mean? For C++, write code whose meaning would change if you used the keyword "virtual" in front of a base class. (Note: passing the test is nowhere near as important as that it generally matches with the answer under #5).
7] (Note: several questions may be done in this area - again, it is more important that skills are accurate on the resume than everything is done exactly right.)
8] Say you have a technical disagreement with a fellow programmer, and you really think you're right. What are the steps you'd take to resolve it?
9] What sort of software tools are you familiar with? How to you coordinate development with other engineers?
10] What are the things you expect from the company for us to make you happy?
I have noticed in interviewing that engineers can easily spot other good engineers. If you can't, it's because you can't program yourself. So go get someone with the skills to do your interviewing for you.
DO ask for demos of working apps from previous jobs/schools. If they don't have anything working to show, they can't take a project, even a simple one, cradle to grave. You want self-starters who don't need constant supervision.
DO NOT make them solve brain-teasers on the spot, regardless of what joelonsoftware.com might say. I love brain teasers personally, but trying to get all the members of U2 across a bridge two at a time doesn't exactly translate. Reread number 1, and if they gave you their stuff, you're safe.
DO ask them to review code from your shop and tell you what they'd do differently. Whitespace, comments, logic that should be pulled into functions or other objects -- these are the kinds of things a good programmer will notice. A good potential team member will even point them out, point blank.
DO NOT discriminate because they haven't programmed in your particular programming language, unless the work is very short term. They're all dialects of the same language. Good code is good code, even VB! (Note that I didn't say "working code" -- I *mean* good, commented, well laid out, non-repetitive code) The only exceptions are pointers and object oriented code. Some people just can't get it. Test them [by showing them code to review] if you use either.
DO look for someone who gets passionate about a topic during your interview.
DO NOT for one second think that someone who claims they have 10 years experience in C, VB, Java, and FORTRAN means it. Ask what they've done which each language. If they can't tell you in enough detail that you can envision it, that's a "no hire".
DO, for heaven's sake, call their references.
And most importantly (and this is something olde Joel gets right), "Maybe" means "Don't hire". If you can't strongly recommend the candidate after the interview, don't hire him/her. Mistakes at hiring time will cost you for months and maybe years. It's worth spending the extra month or two to find someone worth their salt. Oh, man, it's worth it.
It's all 0s and 1s. Or it's not.
Just a comment on the extra-curricular stuff on the resume. I've heard that often HR-types look for that stuff as weed-out criteria, indicating that the person doesn't have enough "real-world" experience and they needed to fill out the resume. Stupid, I know, but you often have to get past the stupid folks before you get a shot at a job.
From my experience, upwards of 90% of jobs come through references anyway, and the interviews are just checks to make sure you're a functioning human being.
-beme
1971
I know the Joke thing would get me. There's no way I'd tell my best jokes to my employer (they just aren't workplace safe), much less my interviewer. Besides, you probably don't want to hear some of the jokes I make to myself when I go out to interview, they aren't very flattering to the employer or interviewer.
I read the internet for the articles.
There seem to be lots of good responses here, many of which I have used myself in the past. But no-one has mentioned my favorite; the 'Toilet Tank Test'.
The 'TTT' is designed to find out if the person thinks about programming off the job, if programming excites them and just doing it is enough to motivate them all by itself. It works like this:
(After technical, logic puzzle and attitude questions are dealt with)
-- First Interview --
INTERVIEWER "OK, so let's suppose I walk into your house and go into your bathroom right now. What magazines would I find on your toilet tank, or wherever else you keep magazines you read often?"
INTERVIEWEE 1 "Uh... Golf Digest, Sports Illustrated, People I guess." (Doesn't mention Penthouse.)
INTERVIEWER "Thank you for your time. Don't call us, we'll call you."
-- Second Interview --
INTERVIEWER (asks 'TTT' question)
INTERVIEWEE 2 "Uh... Linux Journal, Dr. Dobbs, Game Developer I guess." (Doesn't mention Penthouse.)
INTERVIEWER "When can you start?"
Jack William Bell
- -
Are you an SF Fan? Are you a Tru-Fan?
In a corporate development environment, you don't want someone who can only write code based on what they already know. You want someone who can accept a task requiring skills they don't already have - yet deliver quality anyway.
...) then you have a candidate that has a variety of tools in their skills toolbox.
The old adage about "if all you have is a hammer, everything looks like a nail" is what I'm going on about here.
If your candadate only knows one thing ( Java or Delphi, or C++) be wary.
If the candidate knows something useful about a wide variety of things (Java, Delphi, C, C++, shell scripting, XML, XSL, HTML, CSS, Perl, Python, Ruby, batch files, SQL, XQL, servlets, JSP, ASP, PHP
Before anyone chimes in with the old myth "you can only know one thing well" - I agree completely, you can only be an expert in one or two areas. But you CAN know a dozen (or two) things well enough to know which to use - one of the brightest developers I've ever met was a guy smart enought to say "I shouldn't do this - it needs X and I don't know it well enough. Give this to person A and I'll pick up what they are currently doing." This same guy scored 100% on the Java certification exam - he's that good.
Ask your candidate what tools they know - from what vendors. Don't settle for one or two - keep pushing for as many as they mention. Ask them to explain how they would choose between tools - if needed, give them a scenario or three.
One of the things you're trying to find with this approach is how well they might understand the principals that underly the languages - just as you wouldn't ask a fish about water, you can't ask someone who knows only one tool to critique that tool.
Another idea is to get your candidate to give a five minute off-the-cuff presentation on something interesting. Limit it to stuff relevant to the position you're interviewing for, but otherwise leave it open for the person to choose for themselves. They'll choose something they know well - look for how they speak, how well they explain, how well they teach. Also shows how they work under pressure.
After working on computers for 8hrs+ a day I don't feel the desire to go home and code some more. I'd say you should be doing something else at home to keep your interests varied unless you want to hire single minded fanatics.
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
I hate brainteaser questions during an interview.
Wanting to know what my thoought processes are is one thing, but more often than not you're going to expect an answer - and if the candidate takes too long or doesn't get it, what then? Reject them?
One of the worst interviews I had was at Microsoft. 8 straight hours of nothing but linked-list code fragments and MENSA questions.
At the end of the day, I still had no idea what position(s) I had interviewed for, and couldn't tell what any of the folks I talked to actually did. Sort of makes answering "So, would you like to work here?" sort of tough, unless all you want to do is solve brainteasers while your peers look on and say "Come on, you're going too slow."
Why not take your top three candidates and pair with each of them for an hour or two? Pick a task with little domain knowledge needed. Let them drive or do the majority of leading and see what happens...
Then ask yourself (remembering that this is your first pairing with this person)..
Did I like this person?
Did he try to work with me or against me?
Was he technically capable?
Was his technique compatable with yours?
Could he adapt to your style?
Could I corroborate daily with this person?
Does he smell ok?
Did he offer to buy you lunch?
Was he enthusiastic?
If the answers were yes or mostly yes, then you've got a winner.
managers...why god invented purgatory
Unfortunately many programmers/developers also don't realize the difference and think they are both. In truth you can't be one without some of the other, but after a few years you will realize which camp you really excel in. I once worked with a large team of only (good) programmers and it was a nightmarish experience because they didn't appreciate the "development" side of the work, leading to a steaming pile of logistical problems and a missed deadline. Conversely, a team of only developers will likely turn out code with great intentions and design but a weaker implementation.
Its not a matter of being better or smarter or more personable or working better in teams because those skills are valuable to both trades. It really boils down to
To answer the question at the top, I think the first thing you need to do is find out what you have on your staff already, and then establish what you need and interview with that in mind. Looking for the person who does everything and does it well is likely going to lead to dissapointment.
This is not the greatest sig in the world, this is just a tribute.
So what if I'm the kind of programmer who would have to whip out a book to do this? Does that make me a bad programmer? What if my methods and code are far cleaner and efficient than most, and I always produce what I say I'm going to produce on time.. are you going to discount my work as a programmer because I had to look something up? Because I didn't know it on the spot?
Seems far too many people think it's about hotshot know-everything-instantly type of work, where you work when inspired or work when you are 'in the mood'.
What about those who can methodically and cleanly produce code day after day?
Of course, the three-variable version (the one that uses a temp variable) is probably faster on modern machines, as the three-XOR version has a serial dependence that forces it to take 3 cycles. The temp-variable version can go as fast as 2 cycles on a multiple-issue machine, or on an explicitly parallel machine, 1 cycle if the compiler realizes it can optimize one of the moves away in one of the later scheduling passes.
I'm thinking along the lines of the following sequence being executed on a multi-issue machine. (The '||' indicates instructions issued in parallel.)
And in the case where the compiler can allocate 'T' and 'A' to the same register on an explicitly-scheduled machine, the sequence becomes simply:
Can't do that with the three-XOR version.
--JoeProgram Intellivision!
you would expect them to work offline?!?! come on. just give them everything they would have in a normal working environment. do you really want to not hire someone because they forgot to add one little thing? because they didn't have access to the documentation for whatever tools they are using? I am of course saying this all because I'm one of those people who doesn't memorize. I just remember the best places to look when I need a reference for any of the number of languages I've done work with.
also, 90% of work is on the job training... do you expect people to be a perfect match walking in the door? wouldn't you rather have someone intelligent, adaptable and dependable, than someone who really really knows css and frontpage?
I ate my sig.
You have web pages that are lynx friendly.
You are hired.
Sign right here.
-
-
Good luck with everything. Unlike quite a few people
here, you know whats what.
Education does not make you a professional.. it lays groundwork.
Most important thing I ever learned - is how to learn.
<^>_<(ô ô)>_<^>
I did not know SQL. Never did. Did not put it on my resume.
Had a project requiring implementing DB access. I got a book. By the end of the day had it working just fine.. with all fluff and what not.
Our DB guru was reviewing it a bit later and said it was one of the cleanest made solutions he have seen. Note: it was reviewed.
My point being: yeah, when you need an exact narrow skill, or just to weed out liars - sure, that approach works fine.
You will not find people who can learn new stuff, and apply it sucessfully, that way. You will be stuck with jacks of one trade.
On my book - #1 skill is the ability to learn.
<^>_<(ô ô)>_<^>
How about asking hem their nick or email address they usually used and use google to search for the names. If you found them posting comp.lang.c or others technical discussions ( open source or non open source ), it can used as an indicator for how passionate the person is in that field. More posting - better . More posting with sample source code even better.
Am I seeing this right? No-one seems to be saying "look at past work they've done". Look at their source code too, if at all possible, and find out how long past projects took, how many people worked on them, what they did to contribute, how they made technology and implementation choices, how they prioritized design ideals with reality, what major unforeseen problems they ran into and how they solved them, and so forth.
Asking pointed questions about past projects makes it pretty clear whether they have design experience and understand design tradeoffs, whether they can really handle writing a substantial sub-system, and whether they know how to write robust and maintainable code.
Quizzing people and cute interview tactics don't do any of that.
Another thing to consider when hiring doesn't work out: Are your own expectations realistic, or are they failing to work out in an impossible management environment? These are way too common, in my experience, to ignore this side of the hiring coin.
Having sat on both sides of the table (being at the moment on the interviewee side as I'm looking for a job) here's my two cents worth (and worth every bit of sense you can get out of it too).
I don't trust exam type things - especially with pen and paper and looking at specific skills. Indeed, I personally don't tend to care much about specific skills - the organization may need those today, but what about next year? Things change.
The "here's a puzzle, stand at the board and talk about it" is always a good way to find out what how the person works - but don't just go for the right answer - go for the method and how the person reacts to getting stuck and to hints.
(On one such exam (PHD qualifiers actually) I got stuck completely and spent an uncomfortable amount of time trying to unstick myself - but when the examiner said "how about this" - I saw the answer immediately and said "Ah..." It was the "Ah" that the examiner had been seeking. )
I do always ask about a previous project that they enjoyed, and about one they hated (these can be school type projects). For each I try to find out what was the best part, the hardest problem, the worst part... And I'll usually encourage them to talk about team problems as well.
Finally, in the case that the interviewee is undergoing a number of interviews with people in the organization) I encourage interviewees to just relax and take the time with me to decompress (to the extent that they can) and try to just chat about whatever. This gives me a chance to find out if they can talk and know something besides geekdom - which I think is a nice plus.
But you might want to do just the opposite of my ideas - I've managed to make some quite wonderful mistakes. One of my favorites was very talented, but very inexperienced - he had the bright notion that it would be a good thing to send a 2000+ line program to the compiler writers and insist there was a bug in the compiler because it didn't work.
Hmm, come to think of it, that would be a good question : "Have you ever found a bug in a compiler? - How do you know?"
I'll probably get crucified for this....
If you have to include a "technical interview", not to mention 2 of those, then your company is shit. If your hiring manager can't get by with interviewing the guy/gal with some of his/her folks doing an informal interview (that do have some probing tech questions), then your entire structure is fucked.
A bit ago I went through a tough time at my company, so I started out interviewing. I got 3 tech interviews that asked me questions like "what is the command to increase the frame relay delay timing", "what is the public number for public MIBs", and what are the arguments to display only workstations in a Tivoli system?"
Give me 2 minutes with my books, I would have no problem. Expecting me to memorize all this random shit is just beyond stupid. Go find a 5th grader who memorized the nation and state capitals on the 1st try if this is what you want. If you want someone who actually solve a problem, maybe you want to hire someone who can research the problem and come up with a better solution.
I'm still with my first company out of college. The hiring manager didn't even ask about my skills- he wanted to know if I wanted to learn, if I wanted to gain new skills, and if I was willing to put in the time to learn new stuff. Of course, I'm a DoD system and network consultant, so I need to learn and master new stuff all the time. The couple of corporate projects I've been on have so focused on one single aspect that they get a llama that can program in Java, and they still hire the llama. (Yes, that was mostly facitous).
So go interview the guy/gal about who they are, what they want to do in life and in thier job, how they like to do their work. Don't worry about what languages they can program in (unless thi is what you are looking for), any literate computer person can learn a new language in a few days.
In summary, look at the person, not thier certificatons and answers to crazy technical questions.
Vote monkeys into Congress. They are cheaper and more trustworthy.
I don't think I am such a bad programmer, but i don't like the MS type riddles. They annoy me in that there is a single, pre-defined answer. When I am dreaming up a technical solution to a request, I am thinking up something that doesn't have a pre-defined answer. I have seen plenty of solutions that work, but merely parrot the previous solution and ignore any new possibilities that may have come up since. All that results is that we get bogged down in old technology and methods.
Microsoft - Where would you like to go today, Maybe Jail?
If a company asks me a Microsoft-style riddle, I'm outta there. You might as well ask a Trivial Pursuit question instead - it's just testing whether you've seen that riddle before, not testing any brain-power.
The important thing to test in an interview is *method*. Not whether the answer was right, but whether they went through the right steps to get there. If they got the right answer by some random guess, that tells you nothing, but if they went through the right steps and made a mistake, in the real world they can back-track and find the mistake.
Grab.