I've been thinking about interview questions recently. One interview technique no one's used with me: "identify the problem." For example, let's say I asked the

I've been thinking about interview questions recently. One interview technique no one's used with me: "identify the problem." For example, let's say I asked the following question: What I need is a high-traffic scalable document store. The churn of documents is going to be very high and the documents can be very large. I'm going to need to regularly retrieve documents, but mostly only the documents with the closest expire time. How would you go about solving this problem? Now, there are so many variables in this question that asking for a specific solution is practically useless. Instead, it would focus on an interviewee's ability to parse the computer science problem from the stated problem. I would be looking for answers that include possibly building an index of the documents stored in a distributed priority queue architecture. I'd ask them where they expect pain points to be. Good answers would include things like providing document synchronicity across a distributed architecture, providing good failover in case of machine failure, and working out a sane and minimalist communication API between machines. Basically, I'm asking candidates what they should Google if they were trying to solve this problem. The answer given when many coding questions are asked is "I'd Google it," but I've learned that recognizing what to Google is an incredibly hard question. When you start dealing with problems harder than "what was that function in the standard library called again?" it becomes even more useful, because the question now isn't "what do I Google?", it's "What papers do I need to read to understand succesful models of this problem?" I'm just an interviewee still so I've never been able to give this method a try, but I'd be interested to see if results are better or worse than current methods.