I make a list of the kinds of things I expect to be asked based on the company, position and role and then review those things. If I think I'll be writing C th

I make a list of the kinds of things I expect to be asked based on the company, position and role and then review those things. If I think I'll be writing C then I spend a little time re-reading "The Dictionary of Standard C" by Rex Jaeschke and "Hacker's Delight" by Henry Warren so I'll be able to immediately explain what SIG_ATOMIC_MAX means or what (x & (x-1)) accomplishes. If there's a likelihood that I'll be doing any network programming then I'll spend a little quality time reviewing the BSD sources and perhaps re-read my Richard Stevens books so that I'll be able to clearly explain stuff like Nagel's Algorithm (and when it's not a good idea). If I think I'll be looking at a database then I'll review Gray and Reuter's "Transaction Processing" so that I'll keep my SERIALIZABLE, READ COMMITTED, REPEATABLE READ and CURSOR STABILITY straight. If I think they'll want me to do something on the back of an envelope then I'll re-read Jon Bentley's "Programming Pearls" and there's any chance I'll need to actually think about an algorithm (!) then I'll review Skiena's "Algorithm Design Manual". I like to also do a few of Raymond Smullyan's puzzles, just in case I end up in an interview with one guy who always tells the truth and one guy who always lies...