I wish I knew these things when I started
This coming July marks my 3rd year at Google. With my approaching Googleversary, I’ve been musing about my journey from an anxious new grad to a prosperous SWE.
I joined in 2019 right after graduating from The Ohio State University with a B.S in Computer Science and Engineering. I remember being excited
A lot has changed since then.
My journey started with Google’s Engineering Residency Program, a rotational program for new grads that offered exposure to multiple teams within Google and made it easier to build relationships with other members. After completing the program, members frequently convert to full-time roles at Google. The program also offers additional mentorship to help with transitioning from academia to the industry. Sadly, the program no longer exists, so the timing worked out well for me.
Joining Google was an overwhelming experience for me. I couldn’t believe that I had pulled it off. Even if eng res wasn’t quite as good as a standard L3 position, it was an opportunity I couldn’t refuse. I packed up my things and bought a one-way ticket from Cleveland to San Francisco.
During my first rotation on eng res, I worked on the Google TV team. I was eager to show my skills to demonstrate that I was worthy of converting to a full-time role.
I was pretty lucky to end up where I did. I received some outstanding mentorship while working on Google TV. My manager taught me a lot about life; things you don’t learn in the padded walls of university or in the safety of your mother’s basement. I will never forget the value of mentorship after working under him. Every day I had tons of questions for him.
This brings us to the first and probably the most important lesson I’ve learned.
Like seriously, this can’t be understated enough. It doesn’t matter if you are a newly hired L3 or an L5 tech lead. Never be afraid to ask questions. Of course, as you grow and develop, the questions that you ask should change.
If you don’t know the answer to something, find someone who does know. Sometimes, you can find the answer online or in some internal documentation. Sometimes, you need to ask someone on your team or even a different team.
Asking questions can immediately unblock you on a technical problem or unlock new avenues to designing a solution. The faster you unblock yourself, the faster you can complete your task.There is immense value in knowing how to track down information, especially if it’s information that nobody else on your team has. Acquiring new knowledge and sharing it with your team is an incredible way of demonstrating value.
Don’t be embarrassed to ask. The benefits of seeking help outweigh any possible costs. Besides, we all have to learn from somewhere. The senior engineers who seemingly have all the answers probably asked their seniors at some point.
During my first few months, I asked a ton of questions. The best part about working at Google is that you are surrounded by intelligent people. There is almost always someone with an answer out there somewhere. Usually, they will happily share their knowledge.
I managed to deliver significantly more than expected on the Google TV team, so I converted into a full-time SWE early. There wasn’t any space on the team for me, so I landed on the Google Play Movies team. I was excited to be able to learn more on a new team but also anxious about having to ramp up on a completely different product.
Things over there were quite different from what I had become accustomed to on Google TV. Processes were much looser, and it seemed like constant fires needed to be put out. But there was also plenty of work to go around. The engineering lead at the time described it as the “wild west”. I ramped up pretty quickly and landed a lot of small projects. My code submission stats went through the roof. I started to feel like I was becoming a valuable contributor to the team.
Around this time, the COVID 19 pandemic hit in full force. I could spend all day talking about Covid, but I’ll save it for a different story.
Later that year, I underwent my first round of performance reviews. Navigating these processes typically involves more politics and charisma than anything, a far cry from the technical landscape of software engineering. Even if you have the artifacts to prove your accomplishments, you still need to present them in a manner that highlights their significance. Through some trial and error and numerous candid discussions, I learned the next lesson I want to share.
It’s a common belief that managers do the bare minimum to satisfy their reports. Luckily for me, my managers at Google have typically acted with my interests in mind. However, this is not always the case. You should always keep your goals and expectations aligned with your manager. Performance reviews exacerbate this phenomenon more often than anything else. If your boss thinks that rating X will satisfy you, but you actually think you deserve rating Y then you can probably guess the end result.
It rarely hurts to ask for something. The worst that can happen is that you will hear a no. Even if you get denied, now your manager knows what your expectations are, and their goal should be to work with you to ensure that you can justify your request the next time it’s appropriate. Of course, this experience is written with Google’s processes in mind, but these principles can be applied to other companies. The same arguments can be made when asking for a promotion, raise, or title change.
It can be intimidating to ask for things when just starting out on a team. The truth is that your needs and goals are just as valuable as everyone else’s. Don’t let anyone tell you otherwise.
Around this time, Google Play Movies was absorbed by the Android TV organization, and the app was rebranded to Google TV Mobile. Coincidentally I basically ended up back where I started.
The Google Play Movies client depended on Google Play for recommendations and content, while Google TV employed a new content backend owned by Search. To fully migrate to Google TV, our team had to rebuild the app from the ground up to properly migrate to their backend. Although this seems like an unpleasant experience, I found it a blessing in disguise. When helping your team build something from the ground up, you quickly learn how everything works. Additionally, plenty of avenues for demonstrating impact will start to open up. You can implement critical systems and review vital design documents daily. Instead of having to dig through hundreds of lines of boilerplate code, you just have to look at the code that was checked in yesterday to understand how core processes are implemented.
I started to pick up more responsibility for larger projects. One project I became substantially involved in was the Google TV Virtual Remote, a paramount endeavor promoting cross-device experiences in the Google TV ecosystem. However, I learned the hard way that there are only 24 hours in a day. This brings us to our next lesson.
This one is a bit trickier. Obviously, you can’t say no to everything. The real trick is knowing when and how to say no. Alternatively, you can compromise and make things easier for yourself.
If you know you lack the bandwidth to deliver a project to the best of your ability by a specific deadline, you have 3 choices.
- Say that you don’t have time and let someone else take it.
- Compromise on a different deadline or scale back the scope.
- Collaborate with someone else on your team.
There is nothing wrong with either of these options. They are all perfectly OK. It can be hard to say no, especially when you are young and eager for a chance to prove your talent. However, burnout is extremely dangerous, and taking on more than you can handle will only set you back.
Having positive relationships with project managers and UX designers on your team makes compromising a much easier option. Even at big tech companies like Google, the business and engineering sides can fall out of sync. This leads to misunderstandings about what timelines or specifications are feasible. If something isn’t working, notify the PM as quickly as possible. It’s their job to set priorities and deadlines based on the engineering velocity at their disposal.
Once I started pushing for a more senior position, option 3 became the toughest for me to wrap my head around. Giving up work that you know you can deliver can be hard to come to terms with, but part of growing as an engineer is learning how to delegate to the younger engineers and focus on the larger-scale problems.
After launching the virtual remote and the rebuilt Google TV Mobile app, I was finally promoted to L4. The team had changed significantly since I first joined back in early 2020. We had lost four L4 engineers and an L5 tech lead. In their place, we had three L3 engineers join our team, two of them being new grads. Despite my seemingly short 2 year tenure on Google TV, I somehow found myself having more experience than half of the team.
It’s a funny turn of events. When I first joined the team, I looked up to everyone else because they knew so much more than I did. Suddenly, I found myself in the opposite situation. Even though I wasn’t entirely confident in myself, younger engineers looked up to me for help. Here is where I learned the final lesson I want to share.
You should be learning new things almost every day, even if you don’t realize it. This can add up to shocking amounts of information in just one or two years. We easily forget how much we know until we have to start answering detailed questions or help with debugging a test failure. Suddenly, you can explain things eloquently and resolve any stack trace. The technical roadblocks shrink into speed bumps and eventually flatten out completely.
Use this knowledge as a source of confidence. Demonstrate your ability to tackle any project and deliver outstanding results. People notice this bravado, and it can work to your advantage. Interpretation of your work often holds equal weight to its actual quality and quantity.
After I earned my promotion to L4, my attitude shifted. Suddenly, I became more assertive and welcoming toward technical challenges. I started focusing on becoming the leader that people expected me to be through delegation and outstanding technical contribution. I leveraged my thorough technical knowledge of Google TV Mobile to facilitate this transition.
Self-confidence often translates to higher performance, which feeds into the self-confidence loop. The sooner you start this process, the faster you can jumpstart your advancement. Admittedly, it’s challenging to change your demeanor, especially if you just started your career or still suffer from imposter syndrome. Thankfully, this process gets easier over time. Just don’t give up.
I find it crazy how much has changed in just three years (global pandemics aren’t helping). Reflecting on these changes makes me excited for what will happen in the next three.
Putting thoughts onto paper like I am here helps me fully process my thoughts and establish concrete ideas and beliefs that I can share with others. I would encourage others to do the same from time to time.
Full disclosure: everything shared here reflects what I’ve observed in the past three years. My mileage does not necessarily compare to what other software engineers may experience, nor does it fully describe what working at Google is like. I love my job, and I believe that Google is an excellent company. I can’t imagine that I would have been able to receive such incredible mentorship anywhere else. Feel free to follow me, and I may write about life at Google in the future. Thanks for reading!