Price sticky
code review at google

What is Google’s internal code review process?

What is Google’s internal code review process?

You can now consume the entire blog in an audio version.
Give it a try.


We always wonder how big companies like Google who have a glossary of products in almost every sector possible, make sure their code is perfect. It’s for sure they hire the best-talented coders, but writing bug-free code is never the priority of a good programmer. So they must use the Code Review process, and they do! Finding how Google works internally is a tough job unless and until you’re one of the senior members of the development team.

We look at the comments made by two Xooglers. In simple language ex-members of Google – Ben Maurer and Kevin X Chang. Ben is the founder and chief architect of reCAPTCHA, which got acquired by Google as a tool to make its CAPTCHA verification stronger. He left Google in 2010 and has worked for Facebook ever since.

Kevin on another hand as been a software developer at Google and Youtube for more than eight years. He has contributed to AR/VR production DreamLabs and is the creator of ViewPure for YouTube. Both of them have stated similar methods that Google has maintained over the years to perform code reviews. Let’s have a look at how they do it.

Google’s Tool for Code Review

image shows flowchart of google tools for code review

Source: Kevin X Chang

In earlier times, Google used single large repositories called Perforce that were interacted for code review by a layer’ g4 ‘. But they are no longer used. Now Google uses a re-written version of their own created code review tool Mondrian called Critique.

It is a proprietary tool, with lesser knowledge of the outer world but runs on the same functioning as Mondrian. Diffs are centered around ChangeLists (CL). All reviews are done under Mondrian. All changes must be reviewed before checking into the head. A person with a badge of honor that is readable in a particular language will approve the code by adding a comment like “LGTM” (Looks good to me).

Readability in a specific language means that you are writing code that abides by the super strict and precise rule of Google Style Guides. The style guide includes everything, even the punctuation, spacing, alignment – Everything should follow the rules. We’ll discuss all the rules later in this article. Then the code has to be approved by someone with the access to the OWNERS file, which is just based on the hierarchy of Googlers.

None of this information is proprietary as it has been revealed by the maker of Mondrian itself, Guido, in a public video that you can see in this link.

Alternatives for Critique

For non-googlers like me, there are few tools that look and work quite similar to what Google uses. Reitveld is a tool that is nearer to the resemblance of the older version of the Google Code Review tool. It is a fork of Mondrian and is hosted on GAE. It is super convenient to use and enabled on your GAE through the admin panel. Using the python command line, you can upload code diffs from Git, Perforce, Mercurial, and CVS.

Another fork of Mondrian that lets you host your version of the control system is Gerrit. It is very similar to Reitveld but is used mainly in big corporations because of its configure ability from the server to the user side. Even though once used by Google, these tools are outdated and have been replaced by better working code review tools that are automated like CodeGrip.

Rules to do a Code Review at Google

We mention rules that are followed strictly at Google by all engineers to make flawless products to be used by millions of people across the world.

  • All change lists must be reviewed. No matter what.
  • Each directory has its list of owners, mentioned in the OWNER file. The owner is responsible for making sure that the changes and code written fit into the overall codebase. Either one of the authors of the code or reviewer of the Change List will be an owner.
  • At least one reviewer needs to have the readability review badge of honor in a particular language that the developers are working on. The reviewer must follow all of the Google Style Guide rules and use zero tolerance at all points.
  • An engineer can review any change list at any point in time.
  • All reviews are conducted by email or using the Mondrain/Critique interface (as mentioned above).
  • Adding a ‘’ file in the directory will CC add any change list in the directory to the team.
  • To give a favorable vote in the change list is marked by “LGTM” (Looks good to me).
  • Any reviewer can overwrite a positive comment with a negative vote at any point unless the code is marked with “LGTM++” which restricts negative votes from any reviewer.
  • If the author meets all requirements of readability and owner checks, they can submit the change to be read and have a post-hoc review. Reviewers need to check the change promptly, or the system will bombard them with very annoying mails.
  • If commentator makes a negative remark after CL is submitted, the system will harass the reviewer to make the comment positive by submitting another CL that addresses the issue.

Want to get accurate code review results? Sign up now and get instant code review reports for Free!



A complicated and robust process makes sure that talented developers build creative and flawless products. Another reason is that almost everyone depends on Google products in day to day needs, and having a sound code review system gives strength to products to rarely fail. 

Don’t have a team of over 20,000 engineers and researchers who are the best in the world? Still, wish to make products with similar code quality as of Google?

Use CodeGrip, which is free to try an automated code review tool that analyzes, documents, and points out errors, security vulnerabilities, and smells in your code. It suggests solutions to all issues. It also estimates the time to resolve these issues making your code review process as efficient as Google.


Liked what you read? Subscribe and get fresh updates.




    Post a Comment