How Engineering Actually Works Inside Google
Google is not a single engineering org. It is thousands of teams running on different stacks, shipping at different cadences, and maintaining codebases that range from six months old to over twenty years. If you are trying to understand Software Engineering At Google, the first thing to do is stop thinking about it as one methodology. It is a collection of habits, some of which are consistent across the company and most of which are specific to the team you happen to land on. I spent several years working on infrastructure tooling inside Google, and the reality of daily engineering there is less about grand architectural visions and more about navigating bureaucracy while trying to ship code that does not break something three other teams depend on. The pace is fast, but most of the speed comes from removing friction rather than forcing people to move faster. That distinction matters more than you might expect.
Software Engineering At Google and the Code Review Machine
Code review at Google runs through Gerrit, not GitHub. This is not a trivial difference. Gerrit enforces a stricter workflow than pull requests because it was built for a codebase where a single change can touch servers running ads for billions of dollars, search infrastructure, or the Android build system. I once spent three weeks debugging a deployment failure that turned out to be caused by a code review gap. A senior engineer had approved my change on the UI layer, but the backend dependency it called had been silently modified by someone else in a parallel patch that had not been flagged in the review. Gerrit caught it because of its dependency tracking, but not before production metrics spiked unexpectedly for about forty minutes. The workaround was not technical. It was cultural. I started asking for explicit sign-off from the owning team of every downstream service my change touched, even when the review looked clean. That added about two days to my average change cycle, but it eliminated that class of incident almost entirely. You trade speed for stability, which is exactly what Google prefers you to do, ironically enough. Another thing most outsiders miss about Google's review process is the expectation of massive diffs. A single CL (changeset) at Google can legitimately be ten thousand lines long if it is refactoring a subsystem or migrating a protocol. This is not laziness. It is the belief that a change should be reviewed as a complete unit of logic, not split into arbitrary chunks that make sense individually but create regressions when recombined. Junior engineers sometimes struggle with this because they are trained elsewhere to make small incremental changes. At Google, the expectation is the opposite: make the change atomic, explain it thoroughly in the description, and let reviewers focus on correctness rather than chasing half-applied refactors.
The Build System Is Not What You Think
Bazel is Google's build system, and it is both the best and worst thing about working there. It gives you hermetic, reproducible builds that compile identically on your laptop and on a remote executor farm. The first time you configure a rule set correctly, compilation goes from taking forty minutes to four minutes because everything runs in parallel across hundreds of machines. Then you spend three weeks writing BUILD files and you hate it. Here is the nuance nobody tells you: Bazel's performance advantage disappears entirely if your dependency graph is wrong. I worked on a team that had Bazel misconfigured for two quarters. Every developer thought they were benefiting from remote caching and parallel execution. In reality, Bazel was rebuilding the same transitive dependencies from scratch on every invocation because the aspect annotations were pointing at the wrong label types. We had the infrastructure of a fast build system running the equivalent of a naive Makefile. The fix took me about six hours once I realized what was happening, and it involved writing a custom Bazel aspect to audit the actual dependency resolution path. After that, our incremental builds dropped from roughly eight minutes to under thirty seconds. The broader point is that Google engineers spend a disproportionate amount of time on build tooling compared to most companies. This is not because the work is glamorous. It is because a slow build cascades into slower reviews, slower testing, slower deployments, and ultimately slower everything. The company has learned to invest heavily in this layer because it returns compounding benefits.
Get the Full Details
Testing Culture: More Tests Than You Want, Fewer Than You Expect
Google's testing philosophy is often misunderstood. People assume it means writing exhaustive unit tests for everything. It does not. The reality is more surgical. Google follows a testing pyramid, but the base of that pyramid is integration and end-to-end tests, not unit tests. The reasoning is practical: a unit test that passes when the unit is broken is useless, and Google has seen enough of those to know that coverage metrics are a poor proxy for confidence. I remember working on a storage service where we had ninety percent unit test coverage but missed a critical class of failures involving distributed consensus under network partition conditions. The unit tests could not simulate that because they ran in isolation on a single process. What caught the bug was an end-to-end chaos test that randomly killed nodes and injected latency between them. The test suite itself took about four hours to run and required a dedicated cluster, but it caught three separate production incidents that would otherwise have gone undetected for months. The lesson, which took me about two years to internalize, is that testing at Google is not about writing more tests. It is about writing the right tests for the failure mode you are worried about. Most engineers default to unit tests because they are easy to write. Senior engineers at Google tend to invest in integration tests for systems that interact with external services and chaos tests for anything that involves failure recovery.
On-call and Incident Response
On-call rotation at Google is called "on-call" but it functions more like a distributed reliability duty. When you are on rotation, you are responsible for a service or a group of services, and you are expected to respond to alerts within fifteen minutes during business hours and thirty minutes outside them. The pager system is integrated with internal dashboards, so the first page usually includes latency percentiles, error rates, and the recent commit history that might be relevant. The most valuable skill you develop on call is not debugging speed. It is decision speed under uncertainty. I had an incident where search index freshness degraded across two regions. The root cause was a faulty configuration change pushed by an automated deployment pipeline. The pipeline had no human gate. I could have spent an hour tracing through the commit history and the config management system to find the exact change, or I could have rolled back the deployment and restored service in three minutes. I chose the rollback. The incident window was twelve minutes total. The postmortem took longer than the fix. This is the Google way in miniature: ship fast, but have rollback mechanisms that are just as fast. If your rollback is slower than your deployment, you are building a trap for yourself.
Documentation and Knowledge Transfer
Google writes an extraordinary amount of documentation, and most of it is publicly accessible through the Google Search quality guidelines and engineering blogs. Internally, the documentation lives in a mix of wiki pages, Design Docs, and READMEs attached to code repositories. The Design Doc is the closest thing Google has to a formal architecture decision record. Before major changes, engineers are expected to write a one-to-three-page document describing the problem, the proposed solution, alternatives considered, and the failure modes they have thought about. Here is the practical reality: most Design Docs are read by fewer than five people before the change is implemented. The ones that get broad circulation are usually from teams that are restructuring something foundational or introducing a new internal framework. The rest are filed away and occasionally referenced months later when someone hits the same problem. This is not waste. It is a filtering mechanism. If a Design Doc required universal sign-off, nothing would ship. The system works because it relies on social pressure and technical debt awareness rather than formal approval gates. I have seen well-written Design Docs completely ignored during implementation, and I have seen rough one-pagers become the de facto specification for a project. The quality of the document rarely correlates with the quality of the execution. What matters is whether the person implementing the change has actually thought through the tradeoffs, which the Design Doc is supposed to force them to do, whether anyone reads it or not.
Performance Review and Career Progression
Google uses a calibrated review system where managers present promotion packets to a committee. The packet includes examples of impact, peer feedback, and a narrative describing how the engineer has operated above their current level. The calibration process is real and it affects compensation significantly. Engineers who are consistently rated above expectations get faster promotions and larger stock grants. Those who plateau often stay at the same level for years, which is normal and not necessarily a negative signal. The counter-intuitive part is that scope matters more than output volume. An engineer who redesigns a system that affects a thousand other services will often be viewed more favorably than an engineer who ships five times as many features in isolation. This is not said explicitly in any policy document, but it is the pattern that shows up in every promotion packet I have read or been part of. Impact is measured in systemic leverage, not feature count.
What It Does Not Work For
Google's engineering model is not universally applicable. It assumes resources that most companies do not have: large SRE teams, internal build and deployment platforms, dedicated tooling infrastructure, and a critical mass of engineers to sustain the overhead. A startup with twelve engineers trying to adopt Google's practices will find itself buried in process before it ships anything useful. The parts that generalize are the principles, not the implementations. The emphasis on design docs, the preference for rollbacks over hotfixes, the focus on testing for failure modes rather than coverage percentage, the insistence on measuring impact in systemic terms rather than activity terms. These are decisions that scale down. The rest requires scaling up, and most companies do not need to scale up in the same direction. If you are studying Software Engineering At Google, look at the operating system underneath the tools. The tools change. The incentives and tradeoffs tend to stay the same.
