Can I work with you?

You may have interviewed someone recently (or been interviewed yourself) and run into questions like "If a fuse burns over the course of an hour, and you need to measure 45 minutes, how do you do it?" or "Given two strings, find the maximum length substring between them" or "Given a graph, find the minimum cost travel distance across the graph."

Sure, you can probably have a background in any of these questions, but more importantly, do the answers to any of these tell you anything about whether you can work with the candidate, or if they will succeed on your team? I don't think so.

As a web developer, I spend a lot of time fiddling with layouts, debugging javascript, and occasionally writing back-end code so trivial it would make your brain cry. In a lot of business development, you never actually need to solve an interesting algorithms problem, and if you run into such a problem, you can google/StackOverflow/ask around to get a solution.

And yet, during the interview, you're asked (or asking) how you would solve a problem that likely constitutes a negligible percentage of the day to day work that goes on in a company.

Fuck that.

If trick algorithms questions were a test of a developer's merit, then the ACM or TopCoder would be the prime buyer market for employers. They're not, and they shouldn't be. These types of questions only tell you how many of these types of questions a potential candidate has encountered previously, and nothing else.

Here's a better question:
If a customer comes to you and says that occasionally when they click the "run business" button on the application you built for them, how do you go about solving the problem?

An engineer might immediately start talking of deadlocks and race conditions and a million other possible issues, but can they role-play their way to a solution? Do they mention the customer at all, and include customer service and a direct support path as part of their answer?

Depending on what you care about in your business, you can change the role play to learn about the skills and traits you're looking for in an employee.

Here's another question:
If you had to re-build google maps, how would you do it? This was an Apple interview question a few years ago, oddly enough, but I think it's a good one.

An entrepreneurial candidate might avoid a technical discussion altogether, and mention that there's no way that he could built google maps, but teams of designers, engineers, product developers and a boat filled with money might be able to do it.

Does the candidate jump to the problem of scalability, or usability, or coordinating map data and external company interactions? The problem is intentionally open, and how a candidate responds tells their passion and interest.

tldr; Algorithms questions do not a tell you if a developer will succeed on your team. Ask questions that reveal passions and deeper understanding than a rote memorization of KMP.