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.

Coding

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

Working at Google

25. 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.
26. Your experience at Google will heavily depend on what team you are on.
27. Google’s systems interact in very weird ways.
28. I do not envy the people who work on Android. They’re caught in a confusing network of partner teams, OEMs, and legal restrictions.
29. Google has some of the most amazing software tools in the world.
30. 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…
31. (Almost) all code lives in the same repository, known as “google3”. This has to be the largest code base in the world.
32. The repo also is full of mysterious, unowned, untouchable pieces of code known as “haunted graveyards”.
33. No one gets promoted for fixing haunted graveyards.
34. UX is usually underfunded at Google. Meanwhile at Apple, people understand its importance and put their money where their mouth is.
35. It’s hard to make a good UX design.
36. iOS teams often have no UX designer, so they have to use Android mocks.
37. (Almost) everyone at Google is highly competent.
38. Everything must be measured.
39. It is difficult to prove the value of your work if it cannot be measured. This discourages people from doing unmeasurable but necessary work.
40. Most Googlers would like to help you, but their busy completing their OKRs. For the rest the quarter. And next quarter, too.
41. Sundar Pichai is a complicated man. He seems extremely calm for someone at the helm of one the world’s largest companies.

Google’s Culture

42. Getting a massage at work is pretty cool. I should probably fix my sitting posture.
43. You stop being a Noogler when you start complaining about the free food in Google’s cafes.
44. Google has changed in the past six years. Every year, there’s more bureaucracy.
45. The quality of food at Google’s cafes has also declined over time.
46. 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.
47. 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.
48. Google is slowly losing that magical feeling of Googliness present in its early days.
49. 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.
50. No one understands everything at Google. Not even Jeff Dean.
51. Jeff Dean is a genius, but even he makes mistakes (e.g. his conflict with Dr. Timnit Gebru)
52. Dr. Timnit Gebru and Tanja Gupta did not deserve to be fired.
53. Alphabet has a union.
54. 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.
55. The perks really are great.

Career

56. I used to think that technical skills alone are good enough to advance your career. I was wrong.
57. Start thinking about promotion early. Ask your manager what you need to do. Then do it.
58. 1:1s are an opportunity to advance your career. Use them to your advantage.
59. Every job level is another layer of abstraction.
60. At L3, you write code with help.
61. At L4, you write code independently.
62. At L5, you write design docs.
63. At L6, you have meetings about design docs.
64. At L7, you have meetings about meetings.
65. 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.
66. Most of Google’s product problems can be traced to performance reviews (GRAD) and promo.

Management and Leadership

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

Working with Others

79. Scheduling a meeting is a great way to get someone to respond to your e-mail.
80. Everyone needs to do their part to account for unconscious bias.
81. I used to overvalue technical skills and disdain talk about team culture. I was wrong.
82. You probably care more about your work than they do.
83. A good program manager drives projects forward, proactively resolves dependencies, and and is a true leader.
84. A mediocre program manager does little more than update spreadsheets.
85. People (users, colleagues, stakeholders, etc.) will always complain.
86. 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.
87. Listening is an underutilized skill.
88. Some people oppose DEI. I can understand not caring about it, but I do not understand actively opposing it.
89. Antisocial programmers really need to improve their communication skills.
90. Fortunately, you can Dale Carnegie your way through a lot of situations.
91. Ask questions even when you feel embarrassed about asking. People are usually happy to explain the stuff they work on.
92. It is important to give feedback regularly. You have to be humble enough to accept feedback, too.
93. Googlers value feedback. They really want it.

Society

94. We might be at or past “peak software”.
95. Silicon Valley simultaneously understands very much and very little about its users.
96. There’s a lot of money sloshing around in the world.
97. Small is beautiful.
98. Sometimes you have to slow down to go faster.
99. It’s better to put out an MVP quickly than to delay a perfect launch forever.
100. 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.