Speaking from experience on having been on the interviewee and interviewer side of things: Problems where you're asked to use a piece of paper or white board is done because your potential employer essentially wants to know two (2) things about you:
- Are you a problem solver? It might sound elitist and harsh but if you can't solve my problems then why should I hire you?
- Are you able to communicate well about how you solve a problem? You will be working together with a team, the management and sales. Failure to communicate is problematic in a team environment, there are a lot of times during software crafting/development where making one solution may wreak havoc on another. I can't stress enough how important a simple chat would've saved you and your team from dealing with the havoc and come up with an even better solution.
When the problem you're given is done right by the interviewer then you should be able to answer some questions and solve problems without the need of IDE's or other tools. Usually the problems you're given should be answerable regardless of intellisense/autocomplete knowledge as they won't help you anyway on software and algorithm design anyway, so it is a bogus statement if anyone tells you otherwise as those tools only aid your productivity. I wouldn't be surprised if candidates that complain about the lack of IDE are red flagged as copy-and-paste/wizard users rather than "real" coders/programmers.
So if you're in a situation where you have to write code then do the following:
- Take a deep breath. Get that blood circulating in your head.
- Focus on the problem at hand. Everything else is irrelevant.
- And whatever you do: Don't panic! Always assume good intentions. Just so you know: freaking out is a bad sign.
Usually you won't be gauged on syntax correctness anyway. As long as you know what variables, arrays, loops and conditionals are, you should be able to solve problems on paper. Bonus points if you can remember some computer structures and algorithms. Sometimes the interviewer might probe you on typos and it would help to recognize your own mistakes; in such situations just apologize, correct and move on.
And if you want practice, there is Project Euler... or you could just work on real problems writing real applications.