What a week! It started with the lousy first in-person interview on Tuesday, and then several phone interviews, and concluded with another in-person (Friday) morning. From these interviews, and also from interviewing candidates for my current employer, I've made a few observations worth sharing:

• Figure out what your deal-breakers are. Address those a soon as possible with each employer, preferably during the phone interview or before it. Always do a phone-interview first. This will save you from having to take time off work, putting on your suit and tie, and traveling. Before you start scheduling interviews, spend some time reflecting on what's most important to you. Make a list of everything that might affect your decision whether or not to work there. Be thorough with your list but then really focus on the ones that matter most. No place is going to be perfect but you gotta get the big stuff right.
  
• It's possible to be overqualified for a job. By the end of the first interview I had, it was obvious I was years beyond those clowns. They had neither the technology nor the process in place to keep a developer like me happy. The wrong tools, no unit testing, no automated build, no continuous improvement. "Once we hire 15 more people we'll have some time to implement those things." The Mythical Man-Month much? Make sure during the phone interview that you weed these places out.
  
• Watch out for arrogance. This can happen on either side of the table (or phone line). I interviewed with company that sounded like they had a very mature process and was doing cutting-edge stuff... SOA/WCF. The attending staff seemed pretty smart and "with it." The phone-interview went well but afterwards I started analyzing the conversation and realized a few things that bothered me. One thing in particular, when asked what I felt was one greatest strengths, I went with something like "I think I work very well in a leader/mentor role and enjoy teaching other team members about various technologies and practices." The lead interviewer's response was "Well our team is mostly senior developers and we don't need mentoring." Perhaps we misunderstood each other, but that came across to me as very arrogant. I also like to think I'm a pretty good developer, but I know there is always more to learn and ways to improve. I proudly subscribe to Jeff's "Sucking Less Every Year" mentality. I want to work with people that feel the same way.
  
• Sell your strengths. (But don't be cocky.) From the resume to the interview, the point is to make yourself desirable. Tailor your sales-pitch to each employer. (Check out their website ahead of time to get an idea for what they do.) If the employer does a lot of data-centric applications, talk about your database experience... normalization, optimization, O/R mapping, whatever. If you find out during the interview that the employer has not yet embraced automated testing, tell them about how and why you write automated tests. That one in particular has been a hot topic in every interview I have done. I always discuss the mechanics (nunit... cruise control...), the realized benefits (verify requirements, performance, bug fixes), the impact on design (dependency inversion... single responsibility principle...), and even the pains (refactoring for testability... mock objects...). After the interview, the employer is going to review all of the applicants to decide who they want. I want to stack the deck in my favor by focusing in on a few key items that I think will make me stand out from the crowd.
  
• It's OK to talk about mistakes and weaknesses. (But don't overdo it.) We've all made mistakes before and employers know that. What's important is to show that you understood why/how you screwed up and that you learned something from it. Some interviewers will throw in questions design with this purpose. "How do you handle times when you go over budget/estimate?" is a good example. This is a good opportunity to show some personality. Turn it into a war story: "Oh man this one time I had this project..." When asked about a technology/practice that you're unfamiliar with, go with something like "I've never heard of Technology Z. What is that? ... How do you use that here at Company X? ... That sounds pretty cool. Can you recommend a good book or website I could check out to learn more about that?" Just like that you spun the fact that your clueless about that tech into a chance to show you're interested in what the company is doing and that you are enthusiastic to learn new things.
  
• People skills are as important as technical skills. Chief amongst these are good communication skills. Be a good listener and a good speaker. When an employer asks a question, be sure to answer it. Try not to off on too many unrelated tangents. Personality is also important. No one wants to work with an a-hole or a robot. Show some humility and a sense of humor. Hygiene is important too. Would you want to pair program for eight hours with a mouth-breather who hasn't quite mastered deodorant and toilet paper? Neither did I. Show that you are a good team player.
  
• Be professional. Unless explicitly told otherwise, wear a nice suit. Show up about 15 minutes early. Watch the profanity. Depending on your rapport with the interviewer, you may be able to toss in a damn or hell, but definitely avoid f-bombs and genitalia references. I once interviewed a guy that threw in a "Cleveland Steamer" reference during a follow-up interview. Lucky for him I found it freakin' hilarious in context, but I would not recommend you try that one yourself. Present yourself as someone who could be trusted to meet with clients or upper management.