It also the best forum to remind them that my code isn’t perfect either, that this is a process to help make us both better developers.
If something is so unclear that I cannot figure it out on my own, the code / commit message / cover letter likely need to be improved.
Nothing like git-blaming your way to a two-year old commit and get a commit message that actually explains the whys and trade-offs.
I agree that some things do need discussion, but code review tools typically have some sort of chat interface for that purpose. I am doing open source work and most of the time just do code review over the e-mail, which obviously works well for this purpose. [Edit: and of course the calls work as well here! In any case, the result of the discussion should make its way to the code / commit messages / cover letter.]
Yes, absolutely this.
I think it's essential that the reviewer takes their time to inspect the code without distractions and without being rushed.
If you want to have a face-to-face code review, in my experience it works better to have that meeting after finishing the code review, so you can go over your review and discuss each point in greater detail.
Another thing that I maybe didn't make clear enough was it's important to be emphatic, and treat them as equal team-members, even in a Sr to Jr review. Give them an opportunity to weigh in on why they made certain choices and discuss all the pros/cons. Sometimes I even change my mind and agree with their choices when it's clearer what their objectives were.