How do you handle code review, both giving and receiving it?

Split the answer, because the two skills are different.

Giving:

• Separate the blocking from the optional. Say plainly which comments must be addressed and which are preferences — a reviewer who leaves twenty equally-weighted comments is unusable.
• Ask rather than assert when you might be missing context: "what happens if this is called twice?" is more productive than "this is wrong."
• Review the design first and the style second. Style belongs to the linter and formatter, not to a human.

Receiving:

• Treat every comment as a signal that something was unclear, even if you disagree with the fix. If a reviewer misread it, the next reader will too.
• Answer in the code where you can, and in a comment where the reasoning cannot be expressed in code.

Note: If you have introduced a review convention to a team — small pull requests, a template, an agreed turnaround time — mention it. It shows you improve the process rather than just working inside it.