Do you have any advice about how to interview programmers?

As you start hiring, the organism that is the enterprise starts growing and gaining a culture of its own. At the beginning, the influence of a single hire on the culture of the enterprise is huge. Think: "How will this person shape the culture of the company?" As the enterprise grows, you want to make sure that the people you hire fit in the culture that is starting to form.

The interview group: Several people should conduct interviews. When possible, let this be the same group of people. Any member of the interview group should have veto power. When possible, the interview group should include non-techies who are more customer or market facing.

The steps of the interview process: The process we adopt is the following: 1) Reviewing resumes. 2) Phone interviews. 3) In person interviews (round 1). 4) In person interviews (round 2 if needed) and tests. 5) Final sanity check (phone chat) before making an offer.

Tests: We have developed standardized tests that all applicants take. Tests could vary based on the seniority of the position. The tests include: design sections (very important!), code writing sections, and database sections. We usually leave the test until the last round of interviews and use it as a tie breaker.

There is a grading system for the tests that allows for quick elimination of low scoring candidates. For the high scoring group, a deeper dive into the results of the tests is needed.

Never settle for mediocre developers!

Comparing applicants: As you hire your first few developers, you will naturally compare interviewees to each other and aim for the best. Once you have gone through this process a few times, it becomes inefficient to always wait until you have a large enough sample for comparison. At this stage, you should start comparing to people that you have already hired. You will know a good developer when you meet one.

Communication Never compromise on communication. All developers should be able to communicate, verbally and in writing. And no! communicating in Java does not count.
They need to be able to read and comprehend requirement documents, write design documents, communicate statuses, issues, fixes, etc... They should be able to understand and appreciate the end user, the Customer.

All the comments are great.

To add I wanted to share my evaluation criteria. It is always good to have one so you know if your interview roster is missed something.

1. Basic Skills
   This represents basic code and design questions.

2. Drive/Passion
   Dig into their background and look for both drive and passion.

3. Curiosity
   They need to show curiosity beyond the job. I typically like to have an intelligent discussion of current issues in their field.

4. Intellectual/Creativity
   Test them with a tough problem that has lots of latitude, i.e. several solutions, and can always get harder. Look up Google and Microsoft interviews for some hints. Good questions require people at some point to step back and rethink their initial solution.

5. Fit
   See if there is a fit from the interactions during the interview? I also like to ask them what they want to do, what they do not want to do, and why they are changing jobs.

6. Communication
   As Jean-Claude said make sure they can communicate!

7. Ethics
   You want to work with ethical people. Dig into this through questions and reference checks.