The goal is to find errors by having fellow engineers close to the work scrutinize our changes. This review improves the quality of our changes, which also creates the benefits of cross-training, peer learning, and skill improvement. A logical place to require reviews is prior to committing code to trunk in source control.
The principle of small batch sizes also applies to code reviews. The larger the size of the change that needs to be reviewed, the longer it takes to understand and the larger the burden on the reviewing engineer. "There is a non-linear relationship between the size of the change and the potential risk of integrating that change" This is why it's so essential for developers to work in small, incremental steps rather than on long-lived feature branches. Our ability to meaningfully critique code changes goes down as the change size goes up.
Inspect the code review statistics to determine the number of proposed changes approved versus not approved, and perhaps sample and inspect specific code reviews.