Transcription
This is everything I learned during four and a half years at Google, where the projects I worked on provided health search features to hundreds of thousands of daily users, decreased image search viewer latency by 2.31% on mobile, and generated dozens of billions of dollars of revenue per year. I made a lot of mistakes, but grew a lot as an engineer. And today, I'm sharing those engineering learnings with you so you don't have to make the same mistakes.
If you think working at Google is just free food, flexible working hours, and massages, stay till the end of this video for the true reality of it all. Hi friends, I'm Maddie. I'm a senior software engineer who previously worked at Google and intern other big tech companies like Amazon, IBM, and Microsoft. Today I'm going to walk you through the engineering lessons I learned there that really shaped how I build software. These are the engineering habits, cultural norms, and mental models that Google engineers use every single day. And they completely changed how I write code, design systems, and collaborate with teams. So, if you're early in your tech career, preparing for Google interviews, aiming for big tech roles, or even targeting high pressure engineering environments like trading firms, this will give you a serious head start.
One of the biggest mindset shifts I had at Google was learning to write boring code. Earlier in my career, I thought the goal was to write succinct code, the kind that uses elegant abstractions or functional tricks to collapse logic into one tidy expression. But at Google, cleverness is a liability. Once you see code used and maintained at scale, you'll understand why. Google's Tech on the Toilet blog series has a topic called arrange code to communicate data flow and that idea really sums it up. Code should read like a story. Variables appear near their use. The sequence of operations should be obvious and there should be no surprises. When code is boring and predictable, it's easy to maintain even at 3:00 a.m. in the morning during an outage. You're going to thank yourself during your own on call shifts by writing simple, easily readable code.
The next thing Google taught me is that every design must be ready for 10 times today's load. not twice, 10 times. When you're building internal tools or services, you never know which team will depend on your service next month. I remember presenting a design doc for what I assume was a small internal feature. A question I got was, "What happens when we expand the user base to this entire org?" At Google, scale changes quickly. A launch in one new region can multiply traffic. A change in user behavior can shift load patterns overnight. That's why engineers have to think very deeply about sharding, caching, load balancing, back pressure, partitioning, and data distribution. Designing for scale is built into the culture.
Next, let's talk about statelessness. Distributed systems are unpredictable. Machines fail, network partitions, containers get rescheduled. Google's answer to this is statelessness and immutability wherever possible. If your service depends on local state, you're in trouble the moment Borg relocates your container or machine goes down. When state is held in durable systems like Google Spanner, Big Table, or Colossus, your service becomes portable and resilient. Now you can scale replicas without worrying about synchronization. You can restart services safely and debugging becomes so much more simple. Tech on the toilet has posts that reinforce this thinking. For example, limit side effects, make data flow obvious and isolate state. Once you've built systems the Google way, where state is the default, you'll realize that it's one of the biggest stress reducers in engineering.
At Google, writing design docs isn't optional. Yes, design docs are the bane of many engineers existences, including myself. But for better or worse, clear communication is the backbone of engineering. Before implementing anything meaningful, write a design document that forces you to clarify your thinking. Think about what exactly is the problem. What are all the alternative solutions? What trade-offs are you making? What is the status quo? How will this behave at scale? What happens in partial failures? When you're launching, how do you roll out changes incrementally? And in case of failure, how do you roll them back? Design docs also serve as artifacts for future engineers. Five years later or 10 years later, when someone wonders why a system behaves a certain way, they can read the reasoning behind every decision. Reviewing design docs is also how junior engineers learn how to think like senior engineers. Writing them is one of the strongest ways to accelerate your growth. They also allow you to get concrete, actual feedback from teammates and stakeholders before you spend time on implementation.
Next, let's talk about backwards compatibility. Internal APIs often have dozens or hundreds of consumers. Some are well-maintained and some are buried in legacy workflows where no one will notice a break until something slightly fails. That's why Google has strict norms around versioning. You don't remove fields. You don't change semantics. You don't surprise clients. If you must make breaking changes, you introduce new versions and you support old versions far longer than you might want to. Google's Protobuff evolution guidelines exist for exactly this reason. Google's API policy states that new major versions indicate backward incompatible changes, for example, removing fields, whereas new minor versions are for backward compatible enhancements. Google's API guidance AIP 203 lists adding a required annotation to an existing field as an example of a backwards incompatible change.
One of the most impactful testing lessons I learned came from a reviewer who wrote on my PR, "This test relies too much on its dependencies. You should mock out XYZ services." My test case was too tightly coupled to internal implementation details, which meant that any small refactor within its dependent service would break it, even if the behavior in my own code didn't change. Google's testing culture focuses on behavior-driven testing. Tech on the toilet has articles like don't mock the system under test and test behaviors, not methods. The idea is that tests protect guarantees, not structure. And Google uses the Smurf testing framework as a guide. So speed. Unit tests run fastest so you catch issues sooner. Maintainability. Larger, more integrated tests are harder to debug and maintain as dependencies change. Utilization. Lean tests use fewer resources. Unit tests typically scale best. Reliability. Good tests fail only on real issues. Bigger systems introduce flakiness and non-determinism. Fidelity. Higher fidelity tests, for example, integration and end-to-end ones better mirror real production behavior, while unit tests rely on simulations that can drift from reality.
Next, let's talk about Google's build system, Blaze. Blaze's open source counterpart is Basil. Builds must be deterministic. In Blaze, every input is declared and every dependency is explicit. So, the build should produce identical results anywhere, whether it's your laptop or CI. Large scale refactors are much safer with deterministic builds because if your change compiles and passes test locally, it will do the same in prod. This happens at Google almost all the time. I did work on some pretty flaky binaries over the years, though.
At Google, SRRES or site reliability engineers operate under a core truth. Failure is not edge case. It's the default state. A Google SRE is a software engineer who focuses not on building new features, but on making Google's massive systems reliably scale through automation, resilience engineering, and rigorous operational practices. So, ensuring that services meet strict SLOs. While I not so secretly think that you must at least enjoy chaos a little bit to like being an SRE at Google, I think that core truth holds true for regular software engineers as well. Systems must be engineered to expect things to break and to handle those failures predictably. This means designing retries with exponential backoff and jitter, never hammering a struggling service with blind retry storms, and ensuring idempotent writes so a retried request doesn't corrupt data or apply changes twice. Also, it means enforcing deadlines and timeouts so calls don't hang indefinitely and tie up resources. Good failure handling also requires circuit breakers, load shedding, and adaptive throttling to protect downstream systems and prevent cascading failures. You design for graceful degradation, delivering partial responses, cached data, or fallback paths, so users still get something even when the system is unhealthy. At scale, resilience isn't a nice to have. It is an absolute must.
Before Google, I measured performance with P50 latency. At Google, you essentially ignore P50 and focus almost entirely on P99. Users don't feel averages, they feel the slowest responses. In microservice architectures, tail latency compounds. A single slow request can drag down the entire request chain. This is why Google uses strategies like hedge requests, replication, timeout propagation, and careful traffic shaping. Jeff Dean's the tail at scale paper explains this perfectly, focusing on P99 changes, how you debug, how you profile, and how you architect services. When I worked on Google search ads, I learned that even a slowdown of just a fraction of a millisecond on a page could translate to millions of dollars in lost revenue.
One of the most impactful cultural practices at Google is blameless postmortems. When an incident or bad outage happens, no matter how bad, the goal is never to identify whose fault it was. Google assumes that engineers are competent and well-intentioned, and that errors come from systemic gaps, not individual negligence. Postmortems focus on understanding contributing factors, improving tooling, adding safeguards, and preventing similar incidents in the future. The question is never who messed up, it's always how did the system allow this to happen, and how do we change it so it doesn't happen again. This mindset encourages transparency. Engineers feel safe reporting issues early, escalating quickly and sharing root causes honestly. Blameless postmortems build resilient systems and psychologically safe teams. And this is one practice I wish every company adopted.
And finally, being at Google taught me about people as well, not just code. One thing that people might not realize about Google is how kind and humble the engineers are. There's a cultural expectation of helpfulness. People genuinely take time to answer questions, mentor others, and jump into threads even when they're not directly involved. I think that one of the best in the wild examples of googliness came from a Google engineer who was literally on call when he was unexpectedly laid off in the middle of the night. Instead of walking away in frustration, which honestly would have been totally understandable, despite having no access to internal corp resources, he still took the time to figure out how to pay to the next on call to inform them of the situation rather than let his service have no support during the rest of his on call shift. He didn't owe Google anything at that point, but he still did the responsible thing, not because it would affect the job that he no longer had, but because he cared about his team, the service, and the users relying on it. And that attitude is exactly what I saw time and time again at Google. Senior engineers who could easily ignore your question instead sit with you to help you understand a subsystem. That's a deep culture of curiosity and empathy. When you ask for help, no one makes you feel dumb ever. They explain things, point you to documents, or show you patterns they've seen work. That culture makes learning faster and the work environment infinitely better.
In conclusion, here are the engineering lessons I learned at Google. Write boring, readable code. Design for 10 times today's traffic. Use immutability and statelessness to simplify your systems. Write clear design docs for a building. Treat API stability as a contract. Test behavior, not implementation. Use deterministic builds. Assume failure at every level as a default. Optimize for P99 latency, not P50. Use blameless postmortems to grow as a team, not punish individual people. And last but not least, value googliness, kindness, humility, and collaboration. I hope that learning about these habits might help yourself become a more thoughtful engineer. If you enjoyed this video, hit that like button and subscribe, and I'll see you in the next one.