I completely agree that I want to hire programmers who want to constantly learn and improve, but I'm not sure that I should expect them to do so during a stressful high-stakes interview.
I've had good success when we introduce the conversation with "We're going to ask a bunch of questions across a variety of problem domains. We don't expect anyone to be strong in all these areas, but we want to get a feel for where your strengths are, and then we'll drill down into those areas"
But, once you do that setup, everyone is eventually going to say that they don't know what they don't know. It's exceptionally rare for someone to be able to delve into the implementation details of a couple of different programming languages (of our choosing), cryptography, distributed systems, relational modelling, CS theory, and a variety of algorithms and data structures.
So "I don't know" ceases to be much of a signal, since everyone says it a few times.
In fact we prefer to see the opposite, where people are willing to tell us the bits of info that they do know. Even if you don't know how two phase commit is implemented, knowing what problem it's trying to solve will allow you to research it when the need arises.
Because an interview situation is so unlike a normal workplace environment, I don't know any reliable way to translate their willingness (or otherwise) to say "I don't know" in the interview, to on the job behaviours. Either you'll coach everyone into it, or you'll be letting the interview pressure (potentiality) distort their behaviour so much that it's too hard to derive a signal from.
