Ask ten engineering teams what code review is for and you will get ten different answers, usually revealing what actually happens: a rubber stamp to satisfy a branch protection rule, a battleground for stylistic opinions, or an honest, occasionally uncomfortable conversation about whether the code does what it claims to do. We aim firmly for the third.
What we actually look for
A review at Common Sense asks three questions in order: does this solve the actual problem, will the next person who reads this understand it without asking the author, and does it introduce a risk nobody has priced in. Formatting and style are handled by tooling before a human ever looks at the diff, because a person's attention is too valuable to spend arguing about tabs.
We also review scope, aggressively. A pull request that quietly grows from a bug fix into a refactor of three unrelated modules gets pushed back, not because the refactor is unwelcome, but because bundling it with the fix makes both harder to review and impossible to revert independently if something goes wrong.
No ego, on purpose
Comments are about the code, never the person, and every reviewer is expected to explain the why behind a requested change, not just assert it. If a junior engineer disagrees with a senior engineer's comment and has a good reason, the good reason wins. We have changed our own review guidelines more than once because a newer engineer pointed out we were optimizing for the wrong thing.
A review that only ever says looks good to me is not a review. It is a formality wearing a review's clothes.
It slows down the merge button, some days. It has also caught real production incidents before they shipped, more times than we can count, which is the only metric that actually justifies the slowdown.