> I'd agree with his argument if that's what it is, just not his example. I guess I wasn't very clear, then. The parent is correct, my argument did include: "a

> I'd agree with his argument if that's what it is, just not his example. I guess I wasn't very clear, then. The parent is correct, my argument did include: "ability to think about an abstract problem and come up with a solution to it." I was trying to use a bit of brevity in my example but these responses make me believe I oversimplified an actual recent problem I had in mind (which is what I believe make the best interview questions). I do try to attach more business needs to the questions I've asked during interviews. Instead of: "how would you store 1 million strings, search through them while caching results, and make sure only certain individuals can access certain strings" What I really had in my head was: "We have tens of thousands of PDFs that we need to extract text from to make available. That text needs to be normalized. Only certain members of certain teams should have access to different types of text. Additionally, this is going to produce millions of strings. How would you get the PDFs to a place you could use them, extract the necessary text, normalize it, store it, utilize caching to make retrieving it snappy, and ensure correct access?" Technical interviews should be more full of questions that spark conversations where additional inquiries come naturally. What kind of software? What version? What framework? Could you do that faster? And so on. Rattling off whiteboard questions is definitely what I was trying to make an example of avoiding.