A lot of interviewing advice tells candidates to only speak when they are spoken to and to only answer the questions they are given. It is also a cultural thing, in some cultures candidates will absolutely not volunteer any information on the interview. I can't really fault a candidate for doing that.
On the other hand I can create opportunities for discussion, especially when my interests or expertise and the interests or expertise of the candidate intersect.
Sorry I probably didn't explain myself - I mentioned it goes both ways: the discussion should be encouraged by the interviewer (vs "here's a problem I'll check my phone while you whiteboard it"), but the candidate should also seek to do the same - especially if they are senior and good, I expect them to interview me/us. However it's true that it's on the interview to establish an atmosphere where the candidate can be comfortable doing that. I start all my interviews emphasizing this as well as I can, and lead the candidate into questions with stuff like "is there something you would like to know about how we do X here?"
If you don't know why, you must watch this: https://www.youtube.com/watch?v=d-7o9xYp7eE
Also, I never said this is my advice. In general I like to volunteer information during interview when I am the candidate. I think it lets me control the situation a little bit better and move to ground that I have much more expertise in.
I am just saying that I can't fault candidate for not doing this.
Show the candidate a piece of code and let them review it, something they'll actually be doing frequently. You'll get an insight into their understanding of the code and how they communicate improvements.
For a follow-up/bonus round ask them to suggest changes and fix it. A candidate that does this unprompted and well is a positive signal in and of itself.
No stressful whiteboarding and trivia questions. Just a relaxed conversation with their peers that they'd regularly have during work.
I'm also not questioning something I know is right.
Mostly, I just let them code. When they're done, I always say ... are you satisfied? some go back and check, others stand pat, but this lets them take a fresh look.
I then have the opportunity to question something I think in my heart is wrong. I the example, he was right and I was wrong.
For things that look ok, I sometimes start a discussion about embellishments they could add or other techniques.
I really try not to be that guy. I just want to get to know them.
Now I don't worry about questioning a line of code or result since it is an interesting insight into how the candidate thinks and communicates.