I usually see most jobs in software engineering divided in to two categories: One that needs people with lot of plumbing skills and other that needs people to come up with algorithms for hard problems. I do not mean disrespect for the first category - it's an important job. Somebody needs to wire up database to API layer to UX, be very good at optimizing productivity by writing quick scripts, find components and modify them to solve the problem. These are by no means trivial problems. Developers in this group, however, would rarely find themselves writing code for graph traversals or finding common ancestors in trees. Most likely some available library already fits their needs.<p>The developers in 2nd category are different breed. More often than not they need to figure out, for example, how to do breadth first search in distributed way or write code for median in O(n) or do edit distance search on millions of records. For people in this category, CS interview questions aren't merely a check if they were paying attention in their class. Without having demonstrated ability to work on those kind of problems, these candidates would most likely fail in their jobs regardless of their culture fit, passion for the company or wear-all-hats startup attitude.<p>Your interview questions needs to be fine tuned for which category of candidates you are looking for. My personal policy is to ask questions that I faced myself and needed to solve to get the job done. This eliminates several issues such as candidate prepping up from well known questions creating deceiving impression. It also eliminates questions that are not relevant to the job. If candidate floors you with better solution, at least you know you are talking to person smarter than you and would have likely done better job - which is exactly who you want to hire.