Code Review Practices at Google and Facebook: Responsibilities, Processes, and Tools

1. Must do Code Review

At both Google and Facebook, any code that goes to production must be reviewed by at least one team member.

If an urgent production issue is fixed during night or weekend, the change can be deployed but must be marked as TBR (To Be Reviewed), with an automatic review reminder sent daily to the author.

2. Google’s process is stricter

Compared with Facebook, Google has more formal procedures, including a readability qualification process that requires developers to obtain a readability privilege for a given programming language; only code approved by privileged reviewers can be merged.

Readability serves as a credential indicating whether a developer can submit code directly or needs additional checks to meet company‑wide style guidelines. Facebook does not have this requirement, though it also enforces coding standards.

3. Requirements are explicit

Formal code‑review processes demand that all negative review comments be resolved before code is committed to the repository. In practice, reviews may iterate multiple times, with several reviewers required to approve changes.

Google commonly uses the abbreviation PTAL (Please Take Another Look) to request another review round, and LGTM (Looks Good To Me) as the final approval signal; Facebook uses similar but slightly more relaxed conventions.

4. Each company has its own tools

Google uses internally developed tools, one of which inspired the external service reviewable.io. Facebook uses Phabricator, an open‑source tool that also offers a meme feature to make reviews more enjoyable.

Overall, both companies’ code‑review processes aim to foster learning and ensure high‑quality code, though accelerating the review cycle can be challenging, especially for distributed teams across time zones.