So I have this 2 big interviews for a summer internship. One is on monday and the other is on friday. The one on friday is like 3-5 hour interview process. Anyways, I always get nervous during an interview. What are some tips you guys would give to prepare for interviews?

Don't get nervous - believe in yourself and your abilities

However, if you are applying to be a Rocket Scientist and don't have a clue...then be very nervous.

Seriously though...everyone get's nervous at interviews or most do from my experience, and it's probably expected by the people interviewing you and they will allow for that if they're any good. I always used to try and get the interviewee to relax by some general chat about the industry / technology...that seemed to work for me.

If they don't make allowances for your nervousness then they are not worth working for - find a job elsewhere. I've interviewed a lot of very nervous guys and some of them were awesome and I hired them. I wasn't disappointed with the results they produced.

You is what you is...what you see is what you get.

Be professional...and present yourself in that manner.

Let your experience and skills show what you can do.

And breathe

Good luck - let us know how you get on !

Greg

Thanks

1. Do your best to not appear nervous.
2. Be careful not to trail off or give half-solutions.
3. Get yourself to a book store and pick up a copy of "Programming Interviews Exposed" -- Easily the best money I've ever spent on a book.

4. Be yourself

I have failed myself at many interviews...especially coder interviews with a test - mind freeze....even though I can code quite well (25+ years of game development experience so I must be doing something right).

All the best and good luck...once you get in...you may want to get back out again...it's a hard but fun life. Until you deal with publishers....but that's another story

Greg

http://xkcd.com/138/

5. Don't waste anyone's time - if you don't know an answer to their question, don't be afraid to say "I don't know" immediately. We're big sticklers on this where I work.

I would amend #5 to specifically target knowledge-based questions -- eg "What are the three pillars of OOP?" -- but add the caveat that a partial answer to a multi-part question is better than no answer at all.

Also, you might be asked very specific knowledge-based questions and you might not know the exact answer for sure, but still be able to relate it to something that you are fairly certain is similar.

For example, I was once asked something to the effect of "What do you know about the various configuration files in IIS (IIRC), and how are they related?" -- I didn't have specific experience with IIS, but I did know that, in general you have a machine config, and a server config, and a config for each site and that, generally, that settings from the config files that live closer to the site override settings from configs that are further away. I may not be recalling specifics correctly, but I gave my answer to that effect and they were happy enough with it. I got the job (my current, actually) and speaking with the guys who interviewed me they were pretty much pleased with all of my answers, even though I probably only *knew* about 75% of them, and would have probably known only 50% of them had I not studied up on days previous.

For puzzle or programming type questions, its very important not to give up -- and its even more important not to go silent. Its very important to keep talking, even if you're not certain that you're onto the correct solution -- this is expected to happen, and won't count against you. I would recommend starting off by restating the question or problem as you understand it, and mention any assumptions you've been led to make -- verify that those assumptions are correct by asking questions -- again, this is expected and often considered a good thing. Never stop talking for more than about 15 seconds. If you're on a thought for 15 seconds, think out loud -- if you're stuck, say what you're stuck on, how you got there, and consider backing up a bit -- before moving on, state the options you're considering.


Finally, and this goes towards "be yourself" -- don't answer the questions robotically, add a little color. Use of appropriate humor isn't bad. Use jargon and lingo (not too thick) instead of the textbook phrases all the time. If you have a relevant (brief) anecdote, share it -- don't just say "The answer is X.", say "The answer is X. This problem sounds a lot like Y I did with Z." Just don't do this for every question or you'll waste too much time. Keep the professional stuff and the more personable stuff in balance.

Thanks a lot. I know that the interview on friday will test my knowledge on everything, which is why its like 3-5 hour interview. My friend got a job there. Anyone have a link to software engineering concepts? For example, that states the three pillars of OOP( encapsulation, inheritance, polymorphism), and more.

>>Good luck - let us know how you get on

Hey, my first interview went really well. It felt like they were presenting themselves to me rather than the other way around. All my stuff directly related to them and they loved it. Especially, the openGL stuff. At the end
the guy was like we'll probably give you an offer. Whooohoooo. Although, I'm still contemplating about the research with my prof. Now onto the next interview.Thanks so much guys.