Having recently completed another round of campus campus interviews, several things stand out as advice that could be useful to those of you aspiring to get jobs in the software industry as a Developer or Test Developer.

• Always describe what you are doing and thinking – If you are given a programming question and you interact only with the paper or the white board for the next 10 minutes, you did poorly even if you got the answer right.  You failed if you didn’t get the answer right.  The interviewer wants to know not only that you can get the answer but also how you think.  If you have the right thought processes, you might pass the interview even if you don’t get the answer.  Often times people get extra credit for explaining what their options are and why they are picking one or another.
• When asked about a project or job, describe what *you* did – Explaining that the team wrote a location-aware notification system for Android phones doesn’t win you any points if you only did the graphics.  If you wrote the notification database and not the location APIs, talk about the database.  The interviewer will likely probe the details of the project.  Emphasizing the exciting parts you didn’t have a part in only leads to your having so say “I don’t know.  I didn’t work on that.”
• Be able to speak to the details of every project on your resume – If you put it there, it is to demonstrate your knowledge of an area.  If you don’t actually have that knowledge any more, it doesn’t help you.  In fact, it makes you look less knowledgeable.  You don’t have to know every detail of the puzzle game you wrote in that AI class 3 years ago, but you should know enough to talk about the algorithm you used.  Spend the time reviewing and perhaps even practicing talking about each one before showing up.
• If you don’t know, don’t bluff – It is often okay to say “I don’t know…” as long you can also say “…and this is how I would find out.”  It is certainly better than bluffing.  The person interviewing you has probably done a lot of interviews and a lot of programming.  They will likely know that you don’t really know.  Getting caught bluffing almost certainly kills your chances of being hired.
• Think through your code before you start writing – Having to backtrack a lot and change your code is not a good thing.  It is better than being wrong, but it is less good than the next person who will answer the same question without having to backtrack.  Having to add a lot of extra variables or loops or having to change your algorithm substantially demonstrates that you didn’t really understand the problem to start with.  It also makes your code really hard to read because unlike in a text editor, everything doesn’t shift down when you insert a line.  Take the time to think through your algorithm before you start writing.  Even better, explain it to the interviewer.  That way they can correct you if you are on the wrong track.
• Time matters – Sometimes it is not enough to get the solution correct.  Taking a long time to get there, especially if you have to backtrack, shows you do not have sufficient mastery.  Some problems are easy and the interviewer expects you to get them right the first time and without a lot of delay.  Finding a value in a binary search tree or reversing a string fall into this category.
• Be friendly – Believe it or not, your interviewer is human.  He or she will be more inclined to give you the benefit of the doubt if they like you.  Being friendly, making eye contact, and being upbeat all help with this.  If you answer questions with short sentences that do not further the conversation, never make eye contact, and have a sullen attitude, you will fail a close interview.
• Ask clarifying questions – Don’t just jump in and start programming.  Think about what you are being asked to do.  Many times the question will be intentionally vague.  Ask questions about the constraints, the expected use, the interface, etc.  If the question was intentionally vague, not asking questions will be a negative.  Asking intelligent questions shows that you understand the question enough to notice the edges.  That will earn you points.

Have other advice?  Please leave it in the comments.