The level of interest someone has in a subject is generally a good indicator. When it comes to programming, it's not the answers that count so much as how one arrives at an answer. What we need is interactive dynamic analysis of logic. Generally it works best just to have another "great" programmer strike up a conversation with another.
Programming is a bit different than other fields, there are many technically correct answers, but few good answers. In hindsight, identifying a good programmer is much easier, because their creations are easy to debug and work well, even when beyond their design.
A great programmer understands enough stuff that they can debug their creations on a whiteboard without looking at the source code or using a debugger.
I know for myself, I have no background in the Go language. My co-worker came to me telling me he had an issue with an example program where it became slower and slower, very quickly, when it came to lots of channels and go-routines, and he couldn't figure out why. First I started asking basic questions about how the Go language is meant to work, then I asked him how he had his stuff setup, then asked him what he expected. I couldn't find any fault with his setup with my limited understanding of the Go language, but I do understand multi-threading and generally work with complex interacting systems. So my next question was what compiler he was using. Turned out he was using GNU. Then I asked him how they implemented it. After a bit of digging, turned out they used threads for go-routines because threads are much easier to implement quickly for a proof-of-concept compiler. Then I found out they limited how many threads could run at once. This meant that his go-routines, which were blocking each-other, normally would not have an issue in a correctly implemented compiler, but because the number of go-routines which could be processed at a given time was a fixed small number, it effectively created a pseudo-dead-lock, which fixed itself after some timeout that scaled poorly with the number of go-routines. A quick minor change to how the channels were configured, and it ran quickly.
Obviously, in my example, my co-worker is quite smart also, he was able to answer all of my questions or look them up quickly. He came to the same conclusion as I did at the same time. We work well together, which is why my boss paired us. We're great at asking questions. Good answers are hard to come by, good questions are rarer yet.
Having no background in a specific language, I was able to quickly, I think about 15 minutes, figure out a kind-of-deadlock issue in what technically should have worked, by understanding how the compiler implemented "go-routines". My only real-world experience in programming is C#, I don't do any at-home hobby programming, but I do a lot of reading.