Link Details

I always ask how do you test your code. That makes for a fun time! I also ask them what they look for when reviewing others code.

* What OS do you run at home?
if someone run linux i think it means that he doesnt know it and he wants to learn it, so good answer would be windows, right? or he thinks that running linux is so cool that he must use linux. I would say i use ubuntu, however if someone ask that question its just sad.

Framework question is a good one.

I dont understand version control merge question, do people really do it wrong?

Sort question is also good, however i many times find out on job interview that using core api is not a good idea and they believe in writing algorithms and only write sort algorithms.

What OS they run at home can be a jumping point for discussion. This isn't to disqualify a candidate. Somebody running linux to learn it, is somebody *learning in their own time*. Kudos to that person.
This is software, we can't stop learning baby

Merge conflicts happen, it's life (unless you are in the cult of locking files). I want to know if they can work with team members or throw a tantrum.

Yea, there are a lot of people who want to ask compsci questions. Implement a sort, reverse a linked list, etc. Personally, I don't like those. Unless you're fresh out of school, you won't remember. Though, I do study up on those before going on interviews myself.

Why only ask questions? I would ask them to show come to the interview with a good example of his own work, and let him explain it to me. That seems like a very good indicator what you can really expect from the person. It also shows if he is enthusiastic about his work.

I've done that but, then some candidates brought somebody else's work. yikes!!!

I remember that. She could not explain the other persons code either .

I always ask what the person's first programming language was and when they learned it. People who have a passion for the craft of software development will be able to detail exactly what it was and how old they were. I love getting answers like "I was 5, and programming BASIC on my Dad's Commodore64"

Sometimes an applicant's first experience with programming is in college. That's of course just fine - not everyone had the resources to start earlier. When that's the case, I usually ask what they love about programming, and what they're proud of that may not be on their Resume - something that they did on their own time.

I also ask the proverbial "if you had a million dollars" question. That is, if they had all the money they'd ever need, and wouldn't have to work another day in their life, would they still program? Good answers include "of course" and "every day".

Of course, it depends on what type of position you're trying to fill. If you're looking for someone promotable to middle management, look for weaker answers. People who love coding tend to loathe managing people (in my experience).

"""I love getting answers like "I was 5, and programming BASIC on my Dad's Commodore64" """ -- then I wonder what you'd think of my answer -- "From the part of the world where I came, I had never seen a computer until I was 18..."

We are small shop so there is only 1 round interview (i.e. not one screening and then... some other). However apart from what has been said I ask:

* what blogs/web sites do they usually read/visit. Apparently, reading dzone, TSS helps while having mybosucks.com on the list is a minus :)

* obvious "corporate" questions: why she left previous company, what attracts them to work in ours, what are we as a company doing. It is quite stunning how many candidates don't even bother to visit ours web site and try to get some info before going to the interview. It is much more sad and describing the state of SW industry that getting reasonable developers is such a PITA that we must consider even the most ignorant people :(

Asking them about the blogs/web sites they visit/read is a great question! However, I couldn't agree less with the "corporate" one. To be honest, you couldn't care less about the truth. The truth is something along the line of more money, bored of the old job, want to work less hours (big company = good), more vacation, got fired etc. Sure, people visit the web site and come up with some bogus reason as to why they want to work in that company. Most likely your company is not the first choice anyway. Most interviewees probably went to more than one job interview before, so how can your company be the number one choice?

By the end of the interview I want to know 2 things: "can duded code?" and "would I like to work with this guy?"

My favorite question is asking a candidate to write a Singleton, classical Gang of 4 style, on paper, a black board or IDE. Assuming that they can write the basics, I follow up with threading questions, API design questions, and a contrast with the IoC approach to singletons. This touches on a lot of points that a candidate should have experience in. It also brings a lot of passionate theoretical discussions.

I sometimes ask this questions to candidates: "What Interview Questions Do You Ask?" The guys I interview are usually pretty senior. Good senior developers should have played the role interviewer plenty of times. They should therefore have enough experience with interviews to have a formed opinions on interviewing questions and techniques that works for them.

I once got a response like: "It's about a keyword... I forgot what it is." That was wrong on so many levels.

I got another response: "My favorite question is to ask why they used a specific technology that's on their resume." He went on to explain that good technologists will back up decisions with good reasoning rather than "it was there" or "someone else made that decision." That guy earned major browny points. He also happened to have nailed the Singleton question :).