There's a lot of good advice in this thread, and I would suggest studying much of this for your own edification. Cultivate curiosity! That being said, the soft

There's a lot of good advice in this thread, and I would suggest studying much of this for your own edification. Cultivate curiosity! That being said, the software industry has a bit of a fetish for giving these problems in interviews, even though they're rarely used in your job, and there's little evidence that performance on these problems is the best way to evaluate candidates. If you want to be a smart-ass after the interview, study up on Bayes' Law, and lecture your interviewer about it. I.e., p(good programmer|pass interview puzzles) != p(pass interview puzzles|good programmer). If you hire someone because they did well on these problems, you later have data on how well they do at the company. However, you will lack data on how well someone does at the company if they don't do well on the problems (it could be they do just as well), so you have no evidence it's good at classifying candidates. In particular, while I think interview problems are reasonably correlated with talent, I'm not convinced that they're a higher quality source of information than things like whiteboard exercises, real coding exercises, and code samples. It's also biased by things like recency (was your algorithms class last year?) and cramming (be sure to go through Cracking the Coding Interview exercises).