Act as if approving a PR means that if you're the next person to work on that code, you don't get to complain about what a shit job the last guy did on it.
Act as if approving the PR means you share in responsibility for anything that goes wrong once the changes hit prod.
I first try to understand what the pull request is attempting to solve.
Normally we have a good grooming session before working on any tickets, but we push out a lot of work so it’s worth getting full context on what’s going on.
Once I have an understanding of what is being solved (normally on my own or I’ll reach out to the author), I begin looking for clean and concise logic, making sure variable names follow our standard, it uses design patterns and not just spaghetti code, ensure the logic is easy to understand for others on our team (especially newbies), and check that the PR will not cause issues to downstream services.
Afterwards, I check code coverage and the unit tests created, and ensure they are actually testing the right code paths including negative tests, and ensuring mocks are done correctly.
We have a zero tolerance rule for lack of code coverage or improper unit testing (our work involves moving millions of dollars between banks and businesses daily).
After all that is done, I do one last check to ensure I didn’t miss anything then I will either request changes or approve.
For god sakes, please do not rubber stamp pull request. Please always leave feedback, good or bad, so folks know you actually reviewed it.