Another interesting notes about development interviews by Justin James who blogs at Tech Republic.

Takeaway: One of the best ways to calm your interview jitters is to show up prepared. Justin James offers developers pointers on preparing for and, ultimately, acing interviews.

Many developers I’ve met absolutely dread job interviews; this is reflected in my 2008 poll about what developers dislike most about job hunting. If you don’t go on many interviews, it can be daunting to try to prepare for the experience.

Some articles about interviewing make it sound like a dark magic ritual, and you will be doomed if you do not utter the incantations perfectly. The reality is that interviewing is not really that hard; you just need to have an idea of what to expect, know how to handle some uncomfortable questions, and prepare to ask a few questions of your own.

Company research

The advice to research the company prior to the interview is one of those pieces of advice, like doctor’s advice to “start exercising” and “stop smoking,” that everyone hears yet so few people follow. But this tip bears repeating: You must research the company and the position before your first interview. You should spend at least 30 minutes learning about the company’s industry, what markets it services, what its customer base looks like, how the hiring department fits into its overall strategy (if possible), and so on. This research is so important because it lets you talk comfortably about the position and ask pertinent questions. This will also help the interviewer feel more at ease with you and will help the conversation to flow better.

After completing your research, you should come up with a few questions that address any concerns you might have. For example, if your research shows that the project you might be working on is rapidly losing market share, you can tactfully ask what is being done to reverse that trend. It may be a sore spot, but it is better to know the job is to work on a doomed project. No matter what, always frame your questions in a positive way; for example, “What are you doing to keep from going under?” is not nearly as good as, “What is your strategy to regain the competitive advantage?”
Technical questions

You should expect to be asked technical questions. Some interviewers might ask you to solve problems on a whiteboard using pseudo-code, or perhaps ask you to look at code and spot the problems with it. These exercises are designed to see how well you think about working with code without the aid of tools such as an IDE or a compiler. Additionally, the interviewer will get an idea of how well you can communicate things like why you chose a particular solution over another, and whether you are able to explain technical details well.

Typical interview questions might be about simple things like a Fibonacci sequence calculator or a tree walking algorithm. If you take the time to understand the question, you’ll probably be able to answer it with only a minute or two worth of thought. If you flub these questions, it’s almost a guarantee that you will not get the job.

When answering interview questions, it’s very important to tailor your language to the audience. If you’re being interviewed by the senior developer and the lead architect, you can probably be much more technical than if the interviewer is a project manager. If I’m not sure of someone’s level of technical knowledge, the strategy I like to employ is to start with very plain, non-technical language, and say something along the lines of, “I am not sure what your technical background is; I’d be glad to go into more detail if you are comfortable with that.” This shows the interviewer that you are able to communication effectively and appropriately across the board and will not need someone else to “interpret” for the non-technical team members.

You’ll also probably be asked to elaborate on your work history. This is why it is important to not puff up your resume. If it looks like you played a central role in a project and you really didn’t, you’ll be exposed here. Make sure that your resume appropriately states your involvement in projects, and be prepared to go into detail in terms of what you accomplished, the technologies used, and how you used them.

Work examples

If possible, bring some examples of your work. Never, ever bring code from your job unless it is open source or otherwise permissible. Not only will you be in violation of your employment contract, but it makes you look very irresponsible. This is why it’s a good idea to work on an open source project or write a few learning applications at home, because it gives you something that you can use as a code sample. Some employers won’t even do a phone interview without seeing a code sample first.

If you can’t show off your actual code, you may be able to bring screenshots of your application, or point them to it if it is a publicly available application. At one point, I made a Flash portfolio with screenshots of Web sites that I had worked on and included traffic numbers from before and after the redesign to prove that my design and HTML were a substantial improvement; that portfolio impressed a lot of people and was a game changer for when I was interviewing during that period of time. While not every potential employer will ask for code samples, if you’re asked for some and cannot furnish any (or have to scramble to do so), your chances of getting the job are significantly damaged if there are other suitable candidates.
Work style questions

Interviewers will ask you questions about how you work. It is critical to answer these questions honestly, even if you feel like the answer may not be the best. Why? Because chances are that you’re a horrible liar, and because it is better to have a job that fits you than one you hate.

One of the worst pieces of advice out there is in regards to the question, “What is your greatest strength/weakness?” People try giving “clever” answers like, “My weakness is that I love work so much that I come in on the nights and weekends to make sure we hit deadline.” Sounds good, right? Wrong! What’s going to happen when they hire you based on your claim that you’re willing to put in 70 hours a week, and then when you’re on a Death March you are miserable? Now you’re unhappy and a proven liar.

When I’m asked that question, here’s what I tell the interviewer, as painfully truthful as it is: “I sometimes allow myself to get frustrated more easily than I should, and it affects my attitude at times. I’m aware of it, and I’ve been working hard to change it, and I have been making a lot of progress with it over the years.” Am I still “turning a liability into an asset?” Sure. But interviewers appreciate the honesty, and they know that if I am willing to give an answer like that, I can be counted on to not play games with the truth as an employee, either.

It might be a good idea to do a mock interview with someone else so that you get a chance to answer these questions in advance, rather than being caught flatfooted in an interview and seem like you don’t know yourself very well.
Questions for the interviewer

As mentioned earlier, you should have questions for the interviewer. I like to bring a notepad with me (spend a few dollars on a nice one that looks professional), and jot down questions as the interview progresses. For example, if the interviewer mentions someone else’s name and they sound important, ask their role in the project. Take interest and try to get a full and complete idea of the work and the company. Remember, you’re not only trying to sell yourself to the employer, but you’re also trying to find out if the job is right for you.

Excellent questions to ask the interviewer include the following:

Other than (main language being used), what other technologies are involved in this environment?
What percentage of the role is new development compared to maintenance?
Are there any unusual techniques or programming styles that you use?
Are you using an Agile methodology or a Waterfall methodology?
What version control system do you use?
What makes working on this project different from some of the other projects that I have worked on in the past?
Anything else to learn more about the technologies and the project management approach being used.
Can I get a tour of the workspace? This gives you a chance to get a good idea of what the work environment is like, and possibly meet some of the other team members in the process. The tour is one of the most useful parts of the interview, and if you are not offered one, you should politely ask for one if there is time.

Some questions are strictly off limits. Topics you want to avoid include the following:

Anything regarding compensation, unless they broach the topic.
Questions regarding hours of operation (unless the job is specifically shift work, in which case it is fine to ask what shift they’re hiring for), vacation days, dress code policy, break policies, personal phone usage policies, Web surfing policies, whether they record IMs, etc. These questions scream, “I want to get paid for not doing my job!”
Any questions that they would not be allowed to ask you for Equal Employment Opportunity reasons (like ethnicity, religion, nation of origin, etc.). Not only are these questions rude, but they are inappropriate.

Personality quirks

Everyone is unique; however, some folks don’t make a good impression in interviews and don’t get hired because of it. One person I interviewed brought up an argument with a boss from nearly 30 years earlier when asked about previous challenges at work; needless to say, I wasn’t interested in working with someone who held a grudge longer than I had been alive. Another person I interviewed, when asked about competing technologies, had a very dogmatic way of discussing technical matters; this made me cautious because I felt like we would spend a lot of time justifying every decision we made that he did not agree with even if it did not concern him. He was hired anyway and that problem did come up.

Some common quirks that can affect your chances of being hired include the following:

Leg jiggling, finger tapping, etc. These habits make you seem like a nervous person and can also be extremely grating on others’ nerves.
Overwhelming scents, ranging from too much (or too strong) perfume and cologne, lack of deodorant, and cigarette smoke.
Inappropriate jokes. If you wouldn’t tell the joke to a five-year-old, do not tell it at an interview.

It is fine to let some personality show when you interview. I tell jokes (as long as they are appropriate and take no more than a few seconds) and almost always wear a slightly offbeat or unique tie to offset my plain black suit, for example. But you should make sure you’re only showing the positive side of your personality. Before you go to the interview, solicit honest feedback from friends and family about what might give an interviewer a bad impression of you.
Conclusion

A job interview is a lot like a first date; both parties have a limited amount of time to find out as much as possible about each other. By understanding the kinds of questions you might be asked, what behaviors are appropriate, and what types of questions to ask in return, you maximize your chances of not only getting an offer, but knowing if the position and company are a good fit for you.