Code Review is an important part because if something breaks, you’re the first responsible before the developer before you gave a sign off.
SonarQube and Linter checks should ideally be done before the PR is raised by the dev itself.
On code level, as others said variable names, function names should be simple and easy to understand. It should conform to the existing style in the repo. No magic numbers, complex if conditions etc
Next comes the logic. If you’re a good developer you can catch some issues - error cases being handled, panics/seg faults etc. things which can break production
Then the business logic check. Check if the code is doing what it is supposed to do. Via unit tests, or integration tests ensure that this is achieved.
In my personal opinion, PRs should be small and cover a small part of functionality so that they are easy to review. If you have to spend too much time to understand the PR, chances are the code is complex written and wont be easy to understand or debug later. Which can cause frustration in my opinion.
An excellent talk on writing code. If you can write good code, you can do PRs effectively.