It's been some time that I haven't interviewed somebody. I've had a lot of experience of it before on my almost 8 years at Amazon (think somewhere around 400 interviews), but every time that I stop for a month or two, the first interview that I have is never that great.
Interviewing is hard. First thing is that you have to accept that you will be wrong on your assessment from time to time. When you are asking somebody you don't know questions for 30-45 minutes (discounting the time taken to introduce yourself, give a little heads up of what they are being interviewed for and answer questions they might have), you just don't have time to let them fail. If you ask them a question and they go astray with a different and incorrect answer, sometimes it could mean the end of all (or most) of your useful data points.
The other option that I've seen is to just blaze through. If they get something wrong, just move on and ask a different question until you find a question they can find their way mostly to the answer. The problem with that, in my experience, is that some candidates, as they see that they start to fail, they get more nervous and fail more often. It's rare to see a candidate recover correctly from you saying "well, let's move on" when they didn't have a correct answer more than a couple of times.
So my solution is somewhere in between. I try not to stick too long on a question they can't figure out the answer, but instead of moving onto a different question, I try to take their answers apart, extract something that kind-of makes sense, and then build a question around that part. Sometimes it works, sometimes it just takes the interview to routes never taken before and it becomes hard to bring the interview back on topics that I actually know the answer to.
For example, today's candidate started talking about ConcurrentHashMaps. Even though the context in which he was using them was not really that correct (comparing them to using Linked Lists and Arrays), I decided that it was a good idea to just dig deep into what the candidate understood from the topic. And that was great, because I was able to get that he had some right ideas about it, but he clearly thought that he knew more about it than he really did. So he started mixing the design of ConcurrentHashMaps with the design of eventually consistent databases (with version numbers and background processes that would ensure that eventually the last value that came in would be the one that was stored).
Anyway, it was mostly my mistake for taking that path and not knowing how to deconstruct the question enough to get him to realize how the implementation that he was proposing wasn't a good one. So I had to let it pass.
The only other thing that he said that was a little more challenging for me to just accept it is that he called himself "multilingual" when coding. When I asked him which languages he knew he said: Java, Java EE ??, JavaFX (what, the dead JavaFX Script?), XML (oh, maybe he was talking about the XML-based UI language for JavaFX, huh?)... Calling all those different language is a fascinating concept to me. I'm not saying he is necessarily wrong, but I can't really say he is "multilingual" in my definition of the term.
Anyway, I did have a good time talking to him. I'm looking forward to another phone screen in the morning.