This may sound like a truism...Be yourself

dwyn: Right on. As someone who conducts interviews quite a bit, let me state this another way to really drive it home: Do not try to be the candidate you think the interviewer wants you to be.

Over and over again I see people who have obviously crammed C++, OOP concepts, databases or aspects of our business in order to look more like their idea of the ideal candidate. Know this: The fact that you have done this becomes evident almost instantly to a good interviewer, and it is the kiss of death. Why? Because I need to know how well you understand what you have learned. If you say that you know something, and turn out to have only a surface understanding when I ask you to explain how it works, it casts into doubt everything you claim to know. This is the worst single thing that can happen to you in an interview.

During an interview, I am interested in only a few things:

That's it. If you don't know shit about relational databases, don't beat around the bush or make something up about it. Whatever you do, don't start spouting stuff about normal forms unless you can give me some examples from real life. Tell me "actually, I don't know shit about relational databases", or perhaps "We learned about normal forms in college, but I've never had the opportunity to use an RDBMS in a nontrivial way." If you are bright and motivated, I know that I can give you a book, an espresso machine and a generous supply of grind, and tomorrow you will understand relational databases.

The only reason I care about what you know is to determine how deep it goes. If you've been doing object-oriented programming for 5 years now, you better know it inside out. If you don't, or you've only really dabbled in it here and there over the course of several years, say that.

In sum, I am looking for quality. For potential. If you've got it, don't worry...you're golden. If not, well, we're still humming along at 4% unemployment. Somebody will hire you...