It’s best if you can do some prep for the interview. Try to understand what the company’s product is. It’s amazing how cryptic a web site can be, especially if it’s enterprise software in some industry you don’t know. Still, make an attempt, and ask about anything that’s confusing. The fact that you’ve understood some basic things about their product, and that you want to understand more, will set you apart. Of course, it will also help you understand what you’d be doing if you worked there.

Then you should try to read up on the sorts of questions people like to ask. For some reason, people ask algorithms questions far out of proportion to how often they come up in an actual job. Pick up a copy of The Algorithm Design Manual
and read the first section (chapters 1-10) during lunch or in the evening. Even if you only get half way through, you’ll be better prepared than most.

The interview is lopsided: you’ll spend almost all your time answering their questions and only have a little time to ask yours. That’s ok. If you’re still uncertain after the reverse phone screen and the in-person interview, you can always ask to talk to someone on the phone another day.

Keep in mind that they’re trying to figure out whether to hire you. So while it’s good to mention how great this job would be for you, you want to emphasize how great you would be at this job. They don’t really care that you’ve always wanted to learn Lisp and this job would let you do so. They care that you can design & implement software, quickly understand complexity, etc. With that in mind, ask yourself “what are they really trying to get at with this question?” For example, if they ask about a particular job on your resume, feel free to say that another job is probably more relevant and ask them if they’d rather hear about that.

Generally you’ll meet 5-6 people for an hour each, and there are two great questions you should ask everyone. After the initial small talk, ask “What does someone need to be really successful at this position?” Not only will many interviewers think this is a good question for a candidate to ask, but they’ll tell you what they’re looking for. For the rest of the hour, when answering questions, try to answer with stuff related to what they’re looking for. Also, write down the answer. You’ll want to refer to it much later when you’re trying to decide between the different places you interviewed at.

Save the second question for near the end of the hour. “What is the best and worst thing about working at X?” Again, you should write down the answer, because you’ll have 5 or 6 of them from every company you interview at. Both the best and worst thing are important to consider.

Beyond that, here are some good questions to ask:

• What are the day-to-day tasks I’d have?
   
• What day-to-day tasks do you typically do? What have you been doing over the past month?

For a manager:
These were covered in the Reverse Phone Screen post.

For the tech lead:

• How is scheduling done? How are estimates and deadlines created?
   
• How are tasks divided up among programmers?
   
• Who does the overall design/architecture?
   
• Who does the design/architecture of individual contributor’s tasks?
   
• How much time do leads spend with their programmers?
   
• Do you do code reviews? How are they done?
   
• How much do you look over people’s check ins?
   

Good luck, and try to be relaxed and friendly. But most of all, focus on the technical puzzles they give you. If you got into programming because you enjoy that kind of puzzle solving, hopefully the puzzles will at least be interesting.