Interviews for software engineering positions are equal measures normal job interview and extemporaneous logic bomb de-arming with an audience. Most developers know the drill; you stand up in front of one of more senior developers and have to write code on a whiteboard to solve what's normally a fairly academic toy problem, the likes of which you have not thought about since college, what with being busy writing real code for real problems.
Having given countless interviews myself over the last 10 years, I have noticed that a non-negligible percentage of candidates simply lock up when faced with the prospect of whiteboard coding. Many don't seem prepared for this eventuality at all, which is kind of surprising given that I personally can't imagine any decent software companies NOT doing this during an interview.
So, you're going to have to do whiteboard coding. Accept it. The good news is that it's actually easier that coding on a computer. I have personally tried to out-smart the whiteboard by bringing a laptop to an interview, thinking that doing what I do every day would be more successful than the unnatural exercise of coding without a feedback loop. Big mistake.
As a candidate, the person interviewing you should be your feedback loop. That's what they are really after anyway; an insight into how you think about coding. Plus, you only have to write code that looks like it will work to the satisfaction of all parties present. If you whip out a computer, the code will HAVE to be write, because you're going to be running it.
The key to keeping your composure is to practice breaking test problems down into five stages. Restate the problem as they have given it to you. Come up with examples, including edge cases. Work out an algorithm by doing the problem by hand on the whiteboard. Only then do you write some code. Finally, reason out loud about the time your algorithm will take to run. This is known as REACT.
Assuming you get past the technical coding portion of the interview, an additional chunk of candidates flub what should be an easy "softer" portion of the interview. The absolute key to this part is preparation. You're going to be asked questions, mostly of the kind you could guess ahead of time.
Just don't shoot yourself in the foot here. This isn't the time to show your sarcastic, cynical side. You should write out the answers to these questions ahead of time, keeping in mind the answers an employer is going to want to hear.
Then, it's time for you to ask question. In fact, don't even wait for the official offer to ask your own questions, just launch right in whenever you have one that's appropriate, or if there is any dead air time. Your primary goal as an interviewer should be to make the other person talk, ideally even more than you are. People remember conversations more favorably when they did more of the speaking. Plus, it leaves less time for them to grill you.
Again, preparation is key here. You may be meeting up to 10 people at the company. Write out at least 50 questions, ideally more. Think about all the processes, policies and technical decisions you've seen in past jobs, and ask them about how they do those things.
Although live-coding on a laptop is risky, I still recommend bringing one. Occasionally someone will ask you to solve a problem you have actually already solved in real life. In that case, wiping out the code and taking a look at it together could both save you a whiteboard session, and lead to a deeper conversation.