Reviewing code as a new developer can be daunting. I've written a guide to code review best practices to help you.

Atomic Object is a software consultancy specializing in custom software development and product design. Readers can learn about software development methodologies, user-centered design principles, and agile practices. With case studies, blog posts, and technical insights, Atomic Object provides  guidance and expertise for building innovative and user-friendly software products.

Atomic Spin

New developers often find code reviews daunting, but understanding how to write and review pull requests can significantly improve their abilities and confidence. Key steps include ensuring code quality, providing detailed testing instructions, effectively running and testing colleagues' code, and delivering constructive feedback in a considerate manner. Emphasizing a team-focused approach, this guide shares best practices for contributing meaningfully to code reviews and fostering professional growth.

Reviewing Code: A New Developer's Guide

I don’t know when this advice might help me but it will help for sure in future, thanks for sharing!

We have a small team. And most often we conduct reviews with almost the entire team. A main reviewer is appointed, but any member of the team can speak out at any time, so almost always, all mergers are approved collectively.

In our company we review each others code

I really like <a href="https://mtlynch.io/code-review-love/" target="_blank" rel="noopener nofollow">this article</a> from the code review authors perspective.
Code reviews should consist of production-ready code. The code’s design should have already been discussed and agreed-upon prior to implementation, so there shouldn’t be any gripes about major refactors. Code style checks should be automated, so nitpick comments shouldn’t be necessary. The reviewer’s job should primarily be to check for software bugs.