Part of the interviewing process for a software development job is "coding on the whiteboard." Some simple-enough-to-understand problem (such as "FizzBuzz") that shows whether you grok coding or whether you're wasting everyone's time.
The first threshold is understanding that it's foolish to memorize specific "interview code problems," which is, pitifully, something that you see on programmer discussion boards every once in a while.
You can however, do a few simple things that can greatly improve your performance during the job interview:
Take a deep breath
Interviewing problems are always a little tricky -- "Hello, World!" doesn't prove anything and there isn't space on the whiteboard for you to write a Sudoku solver. So interviewing problems will be deceptively easy to grasp. The first thing you write down will not work -- that's the point! Even if you happen to have coded that problem while waiting in the lobby, they'll just say "Oh, ok. Well, how about this problem..." and give you something else.
Take a deep breath. Ask for a clarification or two, even if it's just restating something that was explicitly said: "So, if it's divisible by both 3 and 5, write 'FizzBuzz'?"
Stay true to your principles
Do you believe in tests? Put them on the board first! You don't have to implement a test suite, but if you believe that unit-testing is part-and-parcel of how you should develop, put up some initial input-output pairs.
Do you believe in a source-control workflow? Then at least say "git init, git checkout -b develop, git checkout -b firstfeature." (If they say 'No initial add & commit?' then you win!) Continuous integration? Same thing -- just give a shout-out to your understanding of the programming context and not the programming task at hand.
Refactoring? Coding style? Documentation? Whiteboards aren't conducive to showing these things, but demonstrating your concern for these things will show that you take this profession and your work seriously. But since they are hard to demonstrate on a whiteboard, you should concentrate on...
Talk. Code. Talk. Code. Fire & Displace.
This is a hard one if you, like most programmers, are not used to pair-programming. But realize that whatever problem they've given you is the equivalent of a videogame level -- you're going to get fragged at least once. As I said, if you don't hit a problem, they're just going to give you a trickier task. So, understanding that you're going to get fragged, let them know that the reason you're advancing down this corridor is not because you're stupid, but because you're aggressive .
Of course, just like in an FPS, you don't want to be the person who takes five minutes to scope every corner near the elevator -- you want to show your aggression. So don't just talk -- get code on the board. Does it work? Check your tests you wrote down. Green light? Refactor or at least shout out to adjusting things. Move forward. (Just as I'm now tempted to refactor this whole post into 'Whiteboard coding as Halo level...' but will resist, at least for now...)
Drill in List Processing
I actually began this post wanting to give this one piece of advice. Because it's really one thing you can do to prepare for a whiteboard coding session and not just advice for the moment at hand. If you want to do one thing to improve your chances at solving an interviewing programming challenge, make sure that you've spent a few days in the previous week deeply immersed in processing lists using fold, map, and filter (or their equivalents in whatever language you will be coding in). Practice saying out loud "By applying that to the head of the list and then applying it recursively to the rest of the list, we get something like..."
Even if the language you're asked to code in doesn't have higher-order functions, if you can say "Well, I'd approach it like this in [Lisp | ... | Python]" you're going to show that you can think like a programmer, which is the real challenge.
And, for what it's worth, most whiteboard challenges probably can be solved on a single whiteboard with higher-order functions.
P.S. Use higher-order functions even if being asked to "consider performance." Once upon a time, that consideration would have pushed you towards imperative code. I will admit that I fell into this trap just recently, talking about my concern for memory allocation and cache coherence, when in fact I would have been closer to the ideal solution with the higher-order approach and the magic phrase "Distributed MapReduce" (or the more general principle that in the manycore and cloud era, divide-and-conquer is the key to Big Data).
P.P.S. If you're interviewing for a position writing GPU shaders, you may need to temper your use of recursion. On the other hand, if you're interviewing for a position writing GPU shaders, the whole "Think of coding as a Spartan clearing a level of Grunts and Brutes" is probably all you need...