One that I ask is: Who do you admire from our industry?

Many candidates, the typical its-just-a-job non-passionate programmers, cannot give even one name. Not even 'Bill Gates'.

Sad.

Edit, after receiving comments:

I completely agree with the fact t one doesn't have to admire someone to acknowledge that his/her work is valuable to the industry. So I think the question that best represents what I was trying to ask the candidates is:

Mention the name of one of the influential people in our industry.

If they cannot given even one name, that doesn't tell me much about their ability to code, but definitely affects my decision more than a technical question answered incorrectly.

For a programming job, the best technique is to ask the candidate to solve a simple algorithm in a white/black board.

What do you do to improve yourself as a programmer, so that you do not feel stagnated, to make sure that your programming skills are always up to date?

Ask about a recent project, the candidate's contribution, and then dive a little into the technique. This will quickly reveal 1) if the candidate really understood what he or she was doing or merely copied/borrowed some existing piece of code, 2) if the candidate can explain his or her work to others.

If you could add one feature to your favorite programming language, what would it be?

I like to ask candidates if they write code or develop applications as a hobby. If they answer yes to that, it tells me a lot about them; and in particular, how passionate they are about their chosen profession. It is all too common for developers these days to simply do it because it pays well, and not because they love writing code.

That said, there are plenty of great programmers that do not code as a hobby - but they probably used to.

My favorite programming question was this:

Find the bug in this program:

int main() {
    char *p = malloc(strlen("Hello"));
    strcpy(p, "Hello");
    printf("%s world\n"), p);
}

This worked pretty good for a few years. Some folks recognized the buffer overflow, some didn't. Then one candidate said, with no discernible pause, "Which bug? I see five."

Then I changed the question to "Find as many bugs as you can in this program."

P.s. The five bugs he saw were:

1. no "#include"s to declare the functions.
2. wrong signature for main()
3. didn't check return value from malloc
4. "strlen()" should be "strlen() + 1"
5. no "return" statement.

My single most effective interview question is:

"Imagine you're at home, relaxing, and you decide that you want to check the news. You sit down at your computer, fire up your web browser, and enter cnn.com into the address bar. What happens?"

I've received answers ranging from "The page comes up" to a 30 minute disseration detailing canonicalization, DNS, the transport and application protocols, and more. The beauty of this question is that there isn't really a right or wrong answer; It more speaks volumes to the breadth and depth of their domain knowledge.

Interview for a php dev.

$x = array( 1 => 2 , 2=> 3 );
foreach( $x as $i => $v )
{ 
    print "\$x $i is $v\n";
}

It may look trivial, but if they can't tell you what that gives out ( if they can't even be in the right ballpark ) they have not really used php, and are "chaff". It doesn't mean they're good, but failing that?

Reason being, that 3 lines of code summaries almost 90% of php code.

If you can't use arrays, loops and printing, you're not getting anywhere fast :)

I usually start with something along the lines of:

"Tell me about the tools you currently use to do your job."

I'm constantly surprised by the answers I receive to this one. The point isn't to look for a particular tool or technology, (no VI vs Emacs. vs VS.NET arguments) but rather to quickly assess how much experience and passion they might have for this job.

If a candidate stumbles over themselves trying to tell me that they use Visual Studio... we probably don't need to talk much more. (And this happens way more often than I ever would have thought.)

Conversely, if they start talking about NUnit, or Clover, or Nant, or JIRA, or FogBugz, or CC.NET, or whatever, you all of a sudden have a lot of useful stuff to direct the rest of the interview.

How do you recognize a great programmer?

Show them a really simple code example, with a bit of inheritance involved, and ask them to explain it, line-by-line.

I like to ask which project (or projects) a candidate is most proud of. This gives them a chance to delve into the details of those projects and usually provides a good sense of the person's passion, capability, skillset, etc.

Ask a question based on an answer that has just been given.

Find a decent software problem worth solving, without any tricks and get them to talk out their solution and then do the psuedo code on it. if that is good enough then get them to write it in a programming language of their choice, syntax is not critical but the basic idea.

Could be fizzbuzz could be something else...

Some people cannot remember exact syntax, or are not great writing on the board/paper but through these 3 methods you will figure out if they have a clue.

You are trying to help them show their worth, not to trick them or to make them look bad.

Where is your favourite online source of technical information? With a followup of discussing whether the single word "Google" is a reasonable answer to the first question.

Everyone (should) have a favourite, trusted source - obviously SO is quickly becoming that for all of us - and be able to outline why it is their choice. Being able to make that explanation well - and then to reason through the power and pitfalls of the Google search - is a good sign of an analytical mind.

There are two types of knowledge in this world, that which we think we remember well and that which we know how to find.

I like to set a problem 24hrs or so before the interview. Some thing that requires the use of a fundamental algorythm is good, perhaps entailing a quick sort or the use of linked lists etc. The code should be written as they would any production code and the language should preferably be the one the post will entail but could be in any language of their choosing.

They then email me their answer, I get the rest of the team to review the code and mark it out of 100 based on a standard scoring sheet.

I use the returned code to help short list the candidates.

The code is then used as the basis of a set of interview questions along the lines of 'explain why you've used algorythm X'.

It's not so much what they write but HOW they write the code. Does the code contain error handling, use good structure, etc. They should be able to justify why they used algorithm X to algorithm Y. The code could be cut and paste from the internet but what I'm looking for is an understanding of fundamentals and the ability to decide between 2 or more methodologies and know and to be able to justify why they've made the descision.

"What is the difference between a class and an object". If someone can't get that right (and explain it succinctly" I don't want to waste the next 45 minutes to an hour to tech screen them.

Semi-simple algorithms on a whiteboard are good because:

• The point is not to be clever or have heard of it before. It is to get a good guess about how the candidate will operate on a day-to-day basis on day-to-day problems.
• If there are many solutions, you can see how the candidate approaches many aspects including speed of coding, speed of algorithm, and design quality.
• By asking them to write in syntactically correct code (in their favorite language, assuming you know it a little bit), you get a good sense for how experienced and comfortable they are as a coder. If they mess up easy syntax, it's a big red flag. If they have poor design or out-of-date / questionable patterns, it's a warning.

By 'removing the wheat from the chaff' I'm assuming you're referring purely to technical competency.

I find what gets 85% of them is to solve a question using recursion.

It could be as simple as writing a function that calculates factorial or traverses a tree.

The question that gets the next 5% would be to ask them to write code that they would most often intuitively write in a loop, e.g. write a function that reverses each word in a sentence. Then ask them to change it from a function that loops to one that recurs.

Having to abstract it one level gets a lot of them.

Then I'll ask them if they are familiar with tail recursion (if not I'll explain, no penalty) and ask them to rework the solution to be tail recursive. This gets another 5% of them.

For good measure, I also ask them to flesh out most of the utility methods they use like string.Split.

On an aside, these are the conditions I always test in:

1. The candidate can use their preferred language (we're testing abstract thinking, not language competency).
2. I always let them have excess to a computer for language reference.
3. There is never a time limit.

I find this simple process gives me the remaining 5% that I want to hire.

What open source projects have they participated in?

Say you have a text file with one string per line. How do you find the top ten most frequently occurring strings?

I always start with a question where the answer boils down to "use a map" or "use a set" and I let the candidate answer using any programming language or pseudo-code. This particular question leads to lots of great follow-ups about running time and boundary conditions.

I think it's draconian to have one question where if the candidate answers it wrong, you say don't hire no matter what. That said, it's too easy to get it wrong and still get hired :)

Why do you program?

Well, I used to ask them to sort a million integers in 2MB of memory, but then stackoverflow.com came along...

What kind of developer you are interested to sort from the chaff?

If you want someone for a "quick, we need someone who can code in xyz for our project" maybe you can focus on strictly technical and/or domain related questions.

If you are want to find some long term addition to your team, some more "all rounded" tests can be made (IMHO). So, don't look to much at correct syntax or such things.

BTW, you must obviously check at TheDailyWTF series on interviews ^[1] to get a list of what NOT to do! :)

I find "tell me about examples of bad programming practice" very effective. You would be supprised at the amount of times I need to give them assistance "OK well maybe if you can tell me about some examples of bad programming practice"

Depends on the position, but I tend to pick something they claim to know well, ask a simple question about it, and then follow their answer with increasingly complex/difficult/esoteric questions to learn:

• How well they really know the subject, which gives a sense of their interest and ability to remember details.
• How well they can organize and articulate their thoughts.
• What sort of thought process they have: logical/haphazard, transparent/opaque.
• Whether they'll ask for clarification if they don't understand an intentionally vague question.
• Whether they are honest when they finally don't know the answer, or if they'll try to fake it.
• How they react to potentially stressful situations.

For example, I'll ask a C programmer for the output of the two fragments:

for (i=0; i<10; i++) { printf("%d\n", i); }

and

for (i=0; i<10; ++i) { printf("%d\n", i); }

Then I'll ask for the reasoning behind the answers, and if necessary, ask the candidate to rewrite each for() loop as a while() loop. I'm far more interested in the thought process than the original answer.

I ask "Why are you here ?"

Recursive factorial. doesn't tell if a person knows about a language, but contains enough problem to be discussed to test if the implementor knows what is doing in programming terms. I put this just at start of the interview, to separate early between programmers and experienced copy pasters.

Write a program, that tells how many numbers from 1 to 100 are not dividable by 3?

Can be in pseudo-code, or BASIC/PHP/C or whatever the candidate feels confortable with (But not brainf*ck ^[1] :-)). Simple Example:

count = 0
foreach i in 1 to 100
    if i % 3==0
        count = count + 1
print 100-count

Wrong:

Floor(100/3)

Because the question was: ... are not dividable...

Correct:

100-Floor(100/3)

This show very fast if any programming skills are available.... and how good they are :-)

What aspects do you love about programming?

Ask about previous projects that they have worked on, then get them to draw out the architect/UI screens etc based on that project. It will show if they really understood what they were doing.

Which do you consider the best product/project you have ever worked with? and WHY?

The single most effective interview question I had was to write a small program in a langage of my choice ( Python, at the time ) in one hour.

And there was a full review after it, abour code quality, compliance to goals formatting, error handling and all. I remembre doing OK at the time.

For java, a good and simple "weed-out" question is "give me a general overview of java collections".

Moving things around in maps, lists, etc. etc. is such a basic part of most java code that you can't really accomplish much if you don't have a clear understanding of this. After that I'd move on to more specific technical bits.

Spout off a couple of acronyms and ask them what they think.

Make sure that you phrase the question as if Michael Scott from The Office was the interviewer.

Remember that it is important to say S.E.O. and not Search Engine Optimization. Also, an incorrect contextual use of the acronym is key.

For instance, "If you were to approach our private secure intranet from an SEO perspective, what programming language would you choose to improve our ROI in Google Adwords?"

Since it is unlikely that the private intranet is being crawled by Google, the question doesn't make a lot of sense. If they can patiently explain, without being arrogant, why the question makes no sense -- and if they ask reasonable questions to figure out the problem that you are trying to solve, then it is time to start asking them actual questions about programming.

Ask them to make a simple "Hello World" program.

Then ask them to establish a database connection and make a simple SQL statment from that database.

Most of them were stumped at second step.

Someone applying for a coding job needs to be able to write code. Ask them to solve a basic algorithmic problem in whatever language they'll be using on the job.

I usually have them reverse a NULL-terminated string in place, or reverse a singly-linked list, in C. It's a pretty trivial problem, but it's quite astounding to me how many people fail at this.

I have many data points, and the results are nearly 10%: people who can solve one of these problems quickly (in 5 minutes or less) will turn out to be good programmers. And people who can't, won't.

What software have you shipped to customers?

I generally want to hire someone that has shipped bugs to customers*, so that they've already learned how expensive/painful it is to live with low-quality software.

*shipping software == shipping bugs

My old HR manager taught me to use the classic: "What are your three strengths, and three weaknesses?"

Surprisingly effective, if only because I'm constantly amazed at how many candidates fail to prepare for this question.

Aside from that, just sitting them down with a piece of paper and some programming exercises is very effective.

What is your favorite part of software development and why?

Start from a basic Library application. Users should be able to search and checkout a book from a list of books. Design both database and the classes. Add more complexity depending upon the design.

Get them to solve a few questions from Project Euler.

I wonder how many of these answers are based on the long term success at hiring productive developers, and how many are merely based on what types of questions make for an interesting/enjoyable interview, from the interviewer's perspective?

It seems to me most companies can't even identify the strengths and weaknesses of their current employees that have been their for months or years... Until they can do that, judging prospective employees in a short interview isn't likely to happen.

Disclaimer: I left a job 6 months ago that had a team of 50 working on a big project for 5 years, that's already 2 years late. They aren't done, and from talking to my old coworkers, there's no end in sight. Or actually the end is still 6 months away, just like it has been for the last 2 years. My frequent disagreements with the way the project was run don't necessarily mean I was right, but if I did agree with them all along I certainly would have been wrong. :D

In a past interview I was asked to solve a problem not related to programming at all. It was a question about how best to package and ship ribbons (it wasn't a ribbon company).

The interviewer later told me he always throws one off the wall question in the interview to see if you can give a quality answer for a subject you know absolutely nothing about.

I did well, I guess, but I declined the job offer for a better one. That was a good interview.

My most effective question is one I almost missed, out of nervousness about the guy I was interviewing with (I had heard stories...): show me how you would lazy-load a member variable that you know will be shared among multiple threads.

[He had to remind me by saying, "is that your final answer". I then saw I hadn't used "check twice, load once"]

I use to ask about the last technical book the interviewed read (and when he/she read it), as well as about the reasons of choosing that book and what he/she learned from there.

I consider that if he/she has passion, ambition, he/she will keep reading.

"Why is the manhole cover round" of course, what else?

My favorite question is: if the system goes down, what might be wrong? and how do you find out the causes? and what to do next?

This series of questions can test if the interviewee is a problem solver and his/her experiences. For the question of possible causes, a good candidate can list a bunch of them, from the system itself to its running environment, for example: disk full, too many open files, OutOfMemoryException, network connection interruption, etc. For the question of how to hunt down the problems, a good candidate may also come up a bunch of methods, like application log, OS log, telnet, dig, jvm profiling, etc. For the question of finding out a solution, this question might be the easiest part. But you can also ask if there are alternative solutions? If so, how to choose one of them? This might be tricky. A good candidate might do a cost-benefit analysis to decide.

This is my favorite:

How would you make a social networking site? Whats your approach?

What did you dislike most about your last boss/job/work environment? followed up with

How would you describe your perfect work environment?

The goal being to figure out if they will fit in the team. You can teach them skills, but if they don't fit it's going to be an up hill battle. If everything they hate is what they are going to get, skip them earlier. It's also a way to gauge character/attitude. If they are extremely negative/critical with no diplomacy you've got a red flag for the future.

What is your main intention to join this job in our company.

Tell me about yourself.

You have a bowl with 200 fish in it. Of these fish 99% are not guppies. How many fish should you remove so that 2% of what remains are guppies. Show your work.

My ten-second interview:

How many seconds are in a day?

If someone can't answer that off the top of their head (without having to calculate it), odds are they haven't read enough code to be a good developer.

If they are interviewing for a .Net job, ask them about the favorite episode of .Net Rocks. If they can't answer you with a few that they really love, then ask them if they have any questions for you and politely say goodbye.

Ask them what they think of stackoverflow.com. If they don't have any opinion on it, then the interview is over.

Ok, so these are a little too simplified. But you should really seek questions that aren't loaded like mine above to let them show you how passionate they are about software, or frankly life in general. Most passionate programmers are just as passionate about other things as well. Ask them what they like besides coding.