How to pass an interview

Introduction
Having experience of being an interviewer and an interviewee means I get to see both sides of the equation. As an interviewer I find nothing more tedious than a techie spouting on about how wonderful the new technologies are and how they are the answer to all our problems. The majority of all software projects that fail have nothing to do with the technology and more to do with failures in project management than anything else. Failure to extract the correct requirements and manage them is in my opinion the biggest reason for failure. No ‘cool’ technology is going to solve that problem.

The strongest piece of advice I can give any developer prior to an interview is to demonstrate to the interviewer they are focused on building the simplest thing that will work in order to solve the business problem.

Here are my other tips for successful interview technique:

Firstly, no advice about firm hand shakes, and looking people in the eye. If you are confident and know your subject, the interviewer won’t care if you don’t crush their hand or look at them lovingly!
Look smart. It's irrelevant of course in terms of your ability, but alas, smart clothes create a good first impression. You also might be client facing. So, it’s worth proving that you shower every now and then and know how to put a tie on!
The main purpose of the interview is to hire the 'best fit'. The 'best fit' could be a back room technical geeky genius or someone less technical and more business aware. You'll need to gauge this at the interview. Then you can focus your questions to show that you fit the role they have described.
Never focus on why the role would be good for you and what you would get out of it. The client does not care. They are solely interested in whether they can trust you to do the job on time and to budget.
Never try to pretend that you know something that you don't. You will be caught out. No one hires a blagger. They are far too risky. The boss wants to know that at the end of the day they can trust you to either get something done, or put your hand up and ask for help. Honesty goes a long way. If you have to take a guess, then explain that it is a guess beforehand. If you do not know how to solve something, admit you don't, but suggest how and where you could find the solution. It shows you are resourceful.
Just answer the question. It is easy for techies to 'go off on one' and get carried away by drilling down into some detailed technical area when it is not required. Provide the information necessary and ask the interviewer if that covers what they wanted to know.
Don't interrupt. Remember your manners and wait for the other person to finish speaking. Make notes whilst they are speaking if you are worried you'll forget your points by the time they have finished. Watch out for your eagerness being mistaken for simply being rude.
Try to ensure the conversation is evenly balanced. If they speak for 90% of the time you won't get your points across and be able to impress them. If you speak 90% of the time they will think you talk too much and are a poor listener.
Prepare your questions. Create a set of open questions that provoke conversations about topics which you know a lot about. No one else in that room is going to blow your trumpet. You've got to blow it yourself. Filter your prepared questions that are relevant to the position they have explained to you during the interview.
Unless the position is highly technical then avoid getting bogged down in deep technical discussions that do not give you the opportunity to demonstrate your skills in other areas like software process and lifecycle.
Align your responses based on the interviewer. If they are non technical then don't bore them with deep technical information they know nothing about. They won't be impressed. Use the buzzwords and describe the benefits in terms of how it can help improve the business and hit deadlines. If they are very technical then you might want to get heavily technical to show them you know what you are talking about.
Ask them about the business problem. You are potentially going to be hired as an IT doctor to diagnose and solve their business problems with technology. Your not being hired to use the latest Whizz-bang CV compliant technology, but are there to help their business. Demonstrate that you are focused on providing business value, rather than just using the latest technology to build 'cool stuff'. This is key.
Treat the exercise as a skill matching exercise. You are trying to evaluate if it is a good fit. Be yourself and find out as much as you need to about the role. Don't wait until day 1 to realise that it is 9 months analysis when you would prefer to start designing from already documented requirements.
Show that you know and understand the commercial realities of software development. For example, when suggesting solutions and discussing approaches you should be aware of the difference between tactical and strategic solutions. You should understand why they just want to knock up a quick fix solution, rather than turn a requirement into a software science project. Being aware of the balance between cost of solution and the practicalities is very important.
Show that you have an understanding of where technology is heading. Assuming you read web sites, and journals regularly, ensure you get that across to the interviewer. It is a big bonus if you can show you understand what is coming up, rather than still sticking to old versions of software.
Demonstrate that you understand the project life cycle, together with some formal iterative methodologies. However, don't give the impression that everything must be done formally. Show that you understand the balance between 'over doing it' from and 'getting the job done'.
Never discuss rates and hours with the interviewer unless you have personal commitments that they need to be aware of. If you are worried about 'number of hours' on a daily rate, then get it put into the contract that a day consists of 8 hours of your services. Anything more is chargeable pro rata.
Don't give the impression you know everything. You actually know very little, except a lot about one very small subject. No one likes an ego - they wreck teams and cause mayhem.
Sum up at the end and summarise how you think you can help, and also the areas that you cannot help. For example, you may be great at VBScript, but a novice at JavaScript. Make sure you mention this. If you don't want the job then say so there and then. The interviewer will respect you for saying so.
Do some homework about the company before the interview. A quick hour search on internet will be okay. Get some facts and shoe horn a couple of quotes into the interview to show them that you have found out about the company. It's the fact that you made the effort to find out that is important.
And lastly, show that you are human. Use your sense of humour.