100 Things I’ve Learned as a Software Engineer at Google

It’s amazing to look back over the past seven years. When I first stared this blog, I was a CS student at UT. 99 blog posts later, I’m a software engineer and tech lead at Google. I don’t have everything figured out, but I love showing people earlier in their career how to advance even farther.

Since this is my 100th blog post, here are 100 things I’ve learned while working as a software engineer at Google.

Doing Interviews

  1. No one has the exact set of skills listed in the job posting. The hiring manager is forced to go with the best candidate that shows up.
  2. The interviewer wants you to do well.
  3. The worst interviews are when the candidate struggles hard and can’t make progress.
  4. The best interviews are when the candidate performs exceptionally well.
  5. The hardest interviews are when the candidate is a borderline case, and you lean towards rejecting them.
  6. Structured interviews are necessary, but not sufficient, to remove bias from the process.
  7. Crafting good interview questions is hard.


  1. Code reviews are magic. I’ve learned so much from my code being reviewed.
  2. Small code changes are better than large ones.
  3. Lines of code written is not a good metric. You might as well judge an airplane by how much it weighs.
  4. Dependency injection is magical. Sometimes it is scary.
  5. Everything takes longer than you expect it to.
  6. If you have two dashboards for the same metric, at least one of them must be wrong. Probably both. You’ll try to deprecate one and end up creating a third dashboard.
  7. Don’t look at a dashboard unless you have to. You’ll likely find a “false positive” and waste time trying to debug it.
  8. Nothing is more permanent than a temporary solution (e.g. legacy code).
  9. Infrastructure teams exist so that they can transform O(n) units of work into O(1).
  10. Get an ergonomic keyboard and mouse to avoid wrist problems later.
  11. Programs function in strange ways. Sometimes they do not function in strange ways.
  12. Testing is more important than most people realize.
  13. At the same time, test flakiness is the bane of your existence.
  14. It’s better to prevent a bug at compile time, than runtime, than presubmit, than postsubmit, than in production.
  15. In system design, there is no right answer. This is completely unlike a unit test, which either passes or fails without ambiguity.
  16. Your job is to solve problems, not to write code.
  17. Sometimes a solution that involves no coding is the best solution.

Working at Google

  1. Everything at Google is medium-hard. Impossible tasks become possible, and trivial tasks become difficult. Want to change the color of a button? Medium hard. Want to launch to 1 billion users? Medium hard.
  2. Your experience at Google will heavily depend on what team you are on.
  3. Google’s systems interact in very weird ways.
  4. I do not envy the people who work on Android. They’re caught in a confusing network of partner teams, OEMs, and legal restrictions.
  5. Google has some of the most amazing software tools in the world.
  6. Google takes user data really seriously. Sometimes I have to wait weeks for access to anonymized logs, with all the personal data redacted. And all I wanted to do is was find common events that lead to application crashes…
  7. (Almost) all code lives in the same repository, known as “google3”. This has to be the largest code base in the world.
  8. The repo also is full of mysterious, unowned, untouchable pieces of code known as “haunted graveyards”.
  9. No one gets promoted for fixing haunted graveyards.
  10. UX is usually underfunded at Google. Meanwhile at Apple, people understand its importance and put their money where their mouth is.
  11. It’s hard to make a good UX design.
  12. iOS teams often have no UX designer, so they have to use Android mocks.
  13. (Almost) everyone at Google is highly competent.
  14. Everything must be measured.
  15. It is difficult to prove the value of your work if it cannot be measured. This discourages people from doing unmeasurable but necessary work.
  16. Most Googlers would like to help you, but their busy completing their OKRs. For the rest the quarter. And next quarter, too.
  17. Sundar Pichai is a complicated man. He seems extremely calm for someone at the helm of one the world’s largest companies.
One of Google’s food trucks.

Google’s Culture

  1. Getting a massage at work is pretty cool. I should probably fix my sitting posture.
  2. You stop being a Noogler when you start complaining about the free food in Google’s cafes.
  3. Google has changed in the past six years. Every year, there’s more bureaucracy.
  4. The quality of food at Google’s cafes has also declined over time.
  5. In my opinion, Google hired too quickly in 2020-2022. There wasn’t enough time for all the new hires to absorb Google’s culture.
  6. Memegen is one of the things that makes Google unique. It’s an internal website where employees post memes. If you post enough funny memes you will be invited into the secret Memeacademy.
  7. Google is slowly losing that magical feeling of Googliness present in its early days.
  8. When you have a company of over 170,000 people, just one idiot can make the rest of the employees look bad. Now HR has to institute new rules.
  9. No one understands everything at Google. Not even Jeff Dean.
  10. Jeff Dean is a genius, but even he makes mistakes (e.g. his conflict with Dr. Timnit Gebru)
  11. Dr. Timnit Gebru and Tanja Gupta did not deserve to be fired.
  12. Alphabet has a union.
  13. Peer bonuses are cool. You can give up to 5 to other employees each quarter to reward them for good work. The recipient gets $150.
  14. The perks really are great.
Google’s new Bay View building.


  1. I used to think that technical skills alone are good enough to advance your career. I was wrong.
  2. Start thinking about promotion early. Ask your manager what you need to do. Then do it.
  3. 1:1s are an opportunity to advance your career. Use them to your advantage.
  4. Every job level is another layer of abstraction.
  5. At L3, you write code with help.
  6. At L4, you write code independently.
  7. At L5, you write design docs.
  8. At L6, you have meetings about design docs.
  9. At L7, you have meetings about meetings.
  10. At Google, you’re promoted based on your leadership, impact, and solving difficult problems. It is difficult to get promoted if your contributions are not measurable.
  11. Most of Google’s product problems can be traced to performance reviews (GRAD) and promo.

Management and Leadership

  1. You don’t have to be a manager to be a leader.
  2. Management is different from leadership. Management is about using resources efficiently. Leadership is about having a vision and followers.
  3. Being a good TL is hard. Being a good manager is also hard.
  4. Before starting a project, make sure all stakeholders are on board.
  5. Sometimes the best way to serve customers/clients/users is to make them do no work it all.
  6. Sometimes projects get canceled. It’s nothing personal.
  7. Managers want to see you succeed.
  8. Managers want to unblock you and move the project along.
  9. If a team looks like a well-oiled machine, it’s only by comparison.
  10. One of my favorite parts of my job is mentoring younger engineers.
  11. Crafting a good plan is hard.
  12. Also, nothing goes exactly according to plan.

Working with Others

  1. Scheduling a meeting is a great way to get someone to respond to your e-mail.
  2. Everyone needs to do their part to account for unconscious bias.
  3. I used to overvalue technical skills and disdain talk about team culture. I was wrong.
  4. You probably care more about your work than they do.
  5. A good program manager drives projects forward, proactively resolves dependencies, and and is a true leader.
  6. A mediocre program manager does little more than update spreadsheets.
  7. People (users, colleagues, stakeholders, etc.) will always complain.
  8. The type of complaint you get can tell you whether you’re doing good job. When your manager says the margins should be 4 pixels instead of 2 pixels, you’re doing great. When they complain that “the page is empty”, you have a serious bug to fix.
  9. Listening is an underutilized skill.
  10. Some people oppose DEI. I can understand not caring about it, but I do not understand actively opposing it.
  11. Antisocial programmers really need to improve their communication skills.
  12. Fortunately, you can Dale Carnegie your way through a lot of situations.
  13. Ask questions even when you feel embarrassed about asking. People are usually happy to explain the stuff they work on.
  14. It is important to give feedback regularly. You have to be humble enough to accept feedback, too.
  15. Googlers value feedback. They really want it.


  1. We might be at or past “peak software”.
  2. Silicon Valley simultaneously understands very much and very little about its users.
  3. There’s a lot of money sloshing around in the world.
  4. Small is beautiful.
  5. Sometimes you have to slow down to go faster.
  6. It’s better to put out an MVP quickly than to delay a perfect launch forever.
  7. It is possible for a tiny group to drive huge changes. The path is often difficult and the chance of success usually low. But it is possible.
Posted in Software | Tagged , , , , , , , , , , , | 2 Comments

The One Thing You Need to Understand Before You Write a Resume

Recruiters are busy. With thousands of engineers being laid off from Twitter, Amazon, and Meta, recruiters have boatloads of candidates to choose from. It’s normal for over 200 people to apply for each software development position. A recruiter has the tough task of getting through all the resumes and deciding the small set of people to call in for an interview.

The process looks like this: Before manually reviewing resumes, the recruiter feeds the big “stack” of resumes into a program that checks for keywords. For an iOS developer job, they might select keywords like Swift, Objective-C, software, programming, test, design, iOS, UIKit, performance, reliability, and SQL. Resumes with more keywords get pushed to the top, and resumes with few keywords are automatically rejected.

Then the recruiter does a quick pass through the huge stack. Here, the recruiter spends just 10 seconds looking at each resume to categorize them,

“One down, 199 to go.”

Let me repeat that: the recruiter only has 10 seconds to scan your resume.

It’s nothing personal. Recruiters are human, and each decision requires time and mental energy.

Based on this scan, the recruiter puts your resume in the “yes”, “no”, or “maybe” pile. The people in the “yes” pile proceed to the next phase, either a deeper read, a phone screen, or maybe even an on-site whiteboard interview.

To stand out from the crowd, you need to make your resume easy to understand. Every word ought to have a purpose. The initial scan ought to give the reader a concise summary of your experience and skills and how they match the job description.

So if you’re looking for a job, do a quick scan through your resume or ask a friend to review it. What is the gist that they get? Is it accurate? And how would you improve it?

PS You may be thinking, “It’s really hard to make a memorable impression with a resume.” And I’d say, “You’re right.” If possible, meet some recruiters and managers at a career fair, or ask people in your personal network. You might be surprised at what opportunities are just around the corner.

Posted in Software | Tagged , , , , , , , | 1 Comment

How to Write a Bug Report so that an Engineer Actually Fixes the Bug

If you want an engineer to act on a bug report, it needs to be easy to understand. Most importantly, the recipient needs to know how to reproduce the issue.

The worst bug reports look like this:

Weather query doesn't work

That’s it, no context. It’s impossible to understand what’s going on.

The best bug reports clearly state:

  • How reproduce the issue (“To Reproduce”)
  • The expected user experience (“Expected Behavior”)
  • What actually happened (“Actual Behavior”)

Take this fictional example about the Google Assistant and asking for the weather on the app’s main page (“chat UI”).

Title: Weather forecast ignores user location

To reproduce:
1. Open the app
2. Sign in to your account (or already be signed in)
3. Ensure that "use location" setting is turned ON
4. Type "weather tomorrow" in the query box
5. Tap "Send"

Expected behavior:
Chat UI shows weather forecast at user's location

Actual behavior:
Chat UI shows weather forecast in Santa Cruz, CA *regardless of user location*

This report is easy to understand and as a high chance of being acted on by a developer. It has step by step instructions on how to reproduce the issue. Receiving a report like this won’t be seen as a complaint–rather, this is a legitimate bug that needs to be fixed.

Bonus points: To encourage reporters to provide structured information, create a default template for your bug reports.

Posted in Software | Tagged , , , , | 1 Comment

What if Mario Characters Were Software Engineers?

Welcome to Mushroom Kingdom, Inc. Why don’t I introduce you to some of our software engineers?

Mario is a full stack developer. He has the talent of a rock star, but he’s humble. Everyone turns to him when the project runs into trouble, and Mario always saves the day. He has good relationships with his teammates, doesn’t slack off, follows all of the company’s best practices, and somehow still has good work life balance. His favorite programming language is Java.

Luigi sits next to Mario, his brother. He suffers from severe impostor syndrome despite being a solid developer. Luigi is always second in line when it comes to picking features, and he secretly resents Mario for hogging the spotlight. Luigi only writes tests because his TL told him to, not because he wants to write quality code.

Peach is the team’s manager. She had a great career as a software engineer and has since graduated to become a professional meeting attender. Every once in awhile, she gets to write some code and everyone agrees that it’s top-notch. Peach is a very empathetic leader and she always acts in the best interest of the team. Her one fatal flaw is that she often gets dragged into conflict with her rival, Bowser.

Bowser is a mean manager. He demands perfection, starting yesterday. He hides bugs and sets unreasonable expectations. If a test gets in the way of a new feature, Bowser deletes it without question. He has a backlog of 37 different design documents that will never be reviewed. He hates Peach and Mario–since they always do good work together, Bowser looks bad.

Wario is a maverick. No one is sure why he was hired. Everyone knows he arrives at the office late because he annoyingly revs his motorcycle in the parking lot. Wario regularly insults his teammates, misses deadlines, and delivers buggy code. He refuses to write comments. He claims his “my code is correct without a test” even when it’s demonstrably false. One time, he broke the office toilet and refused to admit it was his fault.

Waluigi is an interesting character. Everyone admits that he’s competent and important, but no one knows exactly what he works on these days. He’s a gregarious guy who likes to party, submits code at odd hours, and somehow hits every deadline that falls on a prime number. His favorite programming language is Haskell. Each of Waluigi’s features has exactly two bugs at any given time. Waluigi thinks that he’s Luigi’s biggest rival, but Luigi doesn’t seem to notice him. Strangely, Waluigi refuses to write unit tests, yet he single-handedly rewrote the company’s integration test framework last year, and will brag about it to anyone who asks.

Daisy is the tech lead of a forgotten internal infrastructure team. Her favorite programming language is Python. She quietly sits in the background and keeps the show running. Every year, she has to remind management why her team exists and they shouldn’t fire her. They look at the flashy numbers from Peach’s team and order Daisy to report the same metrics, even though it doesn’t make sense for an internal service. No one realizes that development would grind to a halt without Daisy and her team.

Posted in Software | Tagged , | Leave a comment

Three Things You Must Do When Mentoring Software Engineers

Mentoring other software engineers is one of my favorite parts of my job.

Every software engineer ought to have an unbiased mentor to go to for career questions. Early in your career, you’re always the one asking questions. As you gain experience, you’ll be called on by other engineers.

So what do you do? I’ve talked with a few software jedis and padawans in my years as a software developer. Here are three things that mentors must do to ensure their mentees are successful.

Backwards-speak, optional is.

#1 Listen

Talking to a mentee is not a time to show off your knowledge. Before you can help your mentee, you must listen to them.

I remember talking with a highly experienced software engineer. I sat down and he started writing down a detailed a career plan, and went on a long, random tangent about how “buying a house is the best investment” that involved the engineer begging the bank to not take his house away. All the while, I didn’t say a single word.

He never asked me what I wanted out of my career. Suffice to say, I did not go to him for career advice again.

If you want to be good mentor, you have to listen. You have to understand what the mentee is looking for. Sometimes they want advice. Sometimes they need help making a decision. Sometimes they know what they must do, and they just want to feel sure about their direction.

Maybe not like Kylo Ren, considering what happened to his mentors…

#2 Don’t directly tell the mentee the answer

Your first instinct might be to directly answer your mentee’s questions. Don’t immediately tell them an answer. The goal here is to lead the mentee to an answer by teaching them how to solve problems on their own.

One pitfall is that the first answer you think is often not the answer that solves their problem. Or even worse, the problem that the mentee thinks they have is not the problem they actually have.

Some time ago, a mentee (let’s call her Leia) came to me for productivity tips. Leia thought she was slacking off in the past month and needed to compensate. When I asked her more, she admitted she was afraid she wasn’t making enough progress at her new job. When we drilled deeper, I discovered Leia was making sufficient progress, but she felt she had nothing to show her manager yet. Therefore, Leia felt she wasn’t living up to her self-imposed, unreasonable expectations, and she felt she was a bad person. Once Leia said this out loud, she realized what was wrong.

At the start of our conversation, Leia didn’t realize that she didn’t need productivity tips. Talking through her thought process was what she needed to get to the answer–to see she was not a bad person, and she was already making good progress at her new job.

#3 Ask Questions

Usually, younger folks come to a more experienced engineer with a question. Sometimes, the questioner must become the questionee.

Asking good questions is interesting art. Each query should let the mentee answer in their own words and talk through their thought process, step by step. It’s a conversation, not an interrogation.

One time, a mentee (let’s call him Anakin) had a tricky situation with his manager. I had an idea about what I would do in that situation, but I wanted to ask for some more details first.

“What should I do?” Anakin asked.

“What have you tried so far?” I replied.

“Well… nothing,” Anakin whined. “I don’t know what to do.”

“What are some things you could try?” I asked.

Eventually, Anakin came up with a number of options for resolving the situation. He picked one and improved his relationship with his manager. I didn’t tell Anakin a single thing. As we met over the next 6 months, Anakin had fewer and fewer questions for me, and he didn’t have to wait for our next conversation to solve his career problems.

In other words, the best mentors teach you how to solve problems without consulting an mentor at all.

If you want to become a mentor, just wait. When the teacher is ready, the student appears.

Posted in Software | Tagged , , , | 3 Comments