I worked in a team of one senior and several juniors (university students at that time, I was one of them). The senior was a guy that had been programming a one

I worked in a team of one senior and several juniors (university students at that time, I was one of them). The senior was a guy that had been programming a one-man-show project for several years and then needed help. In this setup, the guy was respected by all devs and he cared for the product, meaning that he wouldn't accept anything. Also, it's important to say that this senior guy was the one who hired all the others, therefore he had already pre-filtered the less skilled. However, the risk of being swarmed by PRs was there anyway. We did the following things that lead to the improvement of juniors without significantly compromising the quality of the code. - We had an initial meeting where we agreed upon all the general rules and established a baseline for PR quality. (rrwo mentions such general rules in his comment) - PR had two levels of code review. The first round was reviewed by a fellow junior dev who was to review it thoroughly. This round was focused more and code smells and easy-to-spot bugs. Note that all the code review comments should have a relationship to the baseline we had already established so it wasn't just opinions. The second round was done by the senior himself who made sure that the design and complexity is correct. This way, the juniors learned from the seniors and from themselves. Ultimately, - we improved ourselves in giving code review - the gaps between juniors' skills shrunk - senior still had the final say On top of that, you can collect some contentious decisions and have a discussion about them, and incorporate it into the baseline.