The single most useful thing I've found is to find a way to get past the very idea that this is a one-way process, whereby it's supposedly just you who has to prove their (intellectual, economic) worthiness to others (whose own credentials completely beyond question).
In fact you might want to start practicing the complete opposite of this mindset -- just walk in there as if it's you who is contemplating whether to hire them (which in essence is true anyway -- as all truly desirable working situations are two-way streets), and has plenty of other options available if this particular situation doesn't work out. (Paul Graham has a few good paragraphs about this).
Another key conceptual point to keep in mind the fact that while many of these tests are presented as being nominally objective, when in fact their bigger purpose is really psychological -- the interviewer really is just trying to see whether they can "vibe" with you in this interaction as much as whether you are coming up with the right answers. So another thing you want to try priming yourself with (rather than meds) is an an air of simple humility, rather than defensiveness, or again, a need to be seen as always "right" or "worthy" of their assessments.
Some more mundane tips: concentrate on listening(!), maintaining eye contact, and (very important) speaking slowly (because one of the outward signs of anxiety is the tendency to bulldoze past others). Ditto for written Q&A tests, and especially for coding tasks at the whiteboard -- even if you don't normally do so in your own personal habits, find a way to force yourself to write neatly (evenly spaced, properly alignment horizontal / vertical). And when you think it's done, check it again for failure modes and possible optimizations (before the interviewer has a chance to give you that annoying "that's nice. but aren't you missing something?" line).
Basically, it's better to answer fewer questions in more thorough detail than to get through every question the interviewer may have had on his list to ask you. And it's much more important to be neat, cogent and presentable than to be superfast when writing code. And which again, all gets down to basic psychology -- showing the interviewer that you are capable of seeing things from their perspective -- which in essence is what these "tests" are really about, anyway.
Also: as others have said, do develop your portfolio and code samples -- which by all rights ought to speak volumes more than those stupid puzzle sessions).
But as to those puzzles: accept that they are represent a deeply flawed and simple-minded (when you think about it, almost zombie-like) approach to the task of assessing human potential -- but due to a lack of imagination, or simply a follow-the-herd mentality, your interviewers just don't have any better tools to whip out for the occasion -- so you'll just have to "embrace the suck" and find a way to social-engineer your way through them.
By now most of those famous, occasionally interesting (but sometimes also incredibly asinine) puzzle questions have been "leaked" to various places -- dig up as many of those as you can, and spend a few afternoons convincing yourself of your ability to answer each and every one of them. (In particular: techinterview.org, wu riddles, steve yegge's questions, etc).
Even if you miss a few, you can at least be confident that your probability of failure is acceptably low -- and (for the logic puzzles) most of those you do miss probably have some "aha!" flavor to them that doesn't have any functional relation to real-world problem solving anyway. Or you've simply gotten rusty (like many of these interviewers do themselves, particularly in areas that weren't their major focus in school).
Finally, "chill." Don't spend the morning before the interview cramming. Better to lounge around a bit, make sure you've eaten well (but not just before the interview), scoped out the route to get there, etc.
And when it does come to rejection (which is inevitable): keep in mind that it is the very nature of the hiring process, particularly at some of the better places to work, that they have an almost annoyingly high "false negative" rate -- it really is MUCH better on their part to no-hire a good candidate than to hire a bad or insidiously second-rate one (the consequences of which can by very, very expensive). So you're just bound to get rejected from places where you didn't really deserve it.
But sometimes it just so happens that you do deserve it -- because you weren't prepared, or you left some interviewer the impression you were bulldozing past their questions, whatever. Either way, the Zen of dealing with it is NOT to question the rejection; but rather to consider it as a data point: a kind of a failed trade, or a missed sale -- something to learn from, definitely but not (intrinsically) as a sign that your "product" is (ie, you are) damaged goods, per se. And so to the see the rejection as being something fundamentally good (despite the near-term financial and other costs), insofar as it at least teaches you something.
And that of course, every door that closes opens another.