I don't prepare, because it's testing a task that I do pretty much everyday. If I can't do it on-demand I don't see how I can call myself a programmer. That said, I do have some strategies.

Often the interviewer isn't looking for people able to recite detail in the documentation. They are looking at the quality of the code you'll produce. So I concentrate on explaining my approach to the problem, rather than the code.

• How am I going to structure it?
• Where are my concerns?
• What choices am I making about performance?

...and so on. If it's on a whiteboard I'll often write in pseudo-code that looks something like a language, but I'll state that I'm not trying to write perfect, compiler ready code.

I let them guide me to the level of detail they are looking for.

If it turns out they want to score points on me for missing a bracket, or getting the order of arguments wrong, then I take that as a negative against the company. Interviews go both ways, and you're looking for people you can work with too. So if they're going to nitpick in an interview they're probably going to be horrible to work with day-to-day.