1. Pair program.
2. Drive code from tests, outside in.
3. Rotate pairs frequently. Daily for short stories, no more than 2 days for long stories.
4. Review your commits together.
Every other reviewing scheme I've seen quickly becomes an unacceptable bureaucratic drag on forward movement.
At best you wind up with an average of around 2-3 days lag, giving plenty of time for the original engineer(s) to lose context and for the master branch to be well out in front.
At worst you have patches sprinkled around multiple branches of multiple repos, everyone is blocked on everyone else and continuous integration is thought of as a joke about mathematicians.
The original literature on code reviews is based on a very particular and extremely rigid manner of developing software. I think pair programming captures 80% (or more) of the value for less than 20% of the effort and disruption.