I joined Google in October 2022, so I’ve been here about a year and a half now. Looking back, what were my expectations coming into the job?
The Initial Offer and Team Matching
Let me rewind a bit. I signed the offer surprisingly early, back in March 2022. This was even before team matching, so I had no idea which team I’d end up on.
Fortunately, the team matching process worked out well in the end. The first potential match was with an Android team. My recruiter reached out to ask if I was interested, and I was quick to say no. I’m not really into Android development, and mobile development isn’t my primary interest. While I enjoy dabbling with mobile projects sometimes, I didn’t want it to be my full-time focus.
A couple of weeks later, she contacted me again about a team working on vulnerability management. At that point, I didn’t have a concrete picture of what that would entail. Ultimately, I said yes – why not? It sounded more like backend software engineering and distributed systems work, which was far more appealing to me than mobile development.
I then met the hiring manager (who became my manager for the first few months). That meeting went great. A few days later, I also had a chat with the technical lead. They were both incredibly fast talkers, but the work sounded fun, so I decided to go for it.
I accepted the offer, and just like that, I had my team. That was pretty much the prelude. I officially started working in October and joined the team in Munich. Though, initially, Google flew me out to Sunnyvale for the first few weeks, which was a fantastic start.
The “Big Tech” Feeling in the Bay Area
I’d never been to the US before, so visiting and experiencing the Bay Area tech scene was fascinating. The presence of the tech world there is vastly different compared to Munich. Here, even a large office like Google feels… well, just like another company office. It’s nice, you get free food, all the perks you’d expect – but it doesn’t feel particularly special or like you’re part of something massive.
You definitely get that sense in the US, especially in the Bay Area. When you catch a company shuttle, you can choose between dozens of different buildings. That felt wild. Meeting the US-based colleagues I now work with in person was incredibly valuable.
I’m not against remote work at all, but I think meeting regularly, even just occasionally, to talk face-to-face and understand what others are working on is hugely important. Communication feels different in person. Chat is fine, but resolving complex problems often takes more effort via text.
Diving In: Rapid Onboarding Strategy
My approach during those first weeks was to dive in headfirst as much as possible. I believe getting a head start is always crucial. It builds goodwill with your manager and colleagues, allowing you to tackle problems quickly and absorb information rapidly. You can always find a more sustainable pace later.
This is a strategy I’ll definitely repeat whenever I switch teams, projects, or companies down the line. Just intensely focusing for a few weeks at the start. After that initial sprint, you can figure out the right balance: how much work do you want to do, how much are you doing, and how much is expected? Finding that equilibrium takes time. Even with my intensive approach, onboarding still took a while, maybe about a month.
I immersed myself in coding for the first month or two, and productivity really started to ramp up after that. Getting familiar with the code, getting to know people, and navigating code reviews became the focus.
The Critical Role of People Skills
One thing I perhaps underestimated, even after internships, is just how crucial it is to get to know the people who will be reviewing your code. It’s absolutely vital for the code review process itself.
Why? Because everyone has a different style and different priorities when writing code. Some emphasize strict “Don’t Repeat Yourself” (DRY) principles, others prioritize simplicity, and there are many other preferences. You honestly can’t satisfy all of them simultaneously.
Sometimes, with a specific piece of code, you have to make a choice – you can lean into one principle or another, but you can’t perfectly achieve everything without spending excessive time on it.
Knowing who your reviewers are allows you to anticipate their preferences and subtly adapt your coding style accordingly. I guess it’s similar to “code-switching” in language, where you vary how you speak depending on who you’re talking to.
Applying this to code reviews means you vary the “dialect” of your code based on your audience. This helps get your changes submitted much quicker, which is essential for team velocity. You spend less time debating why you made a certain choice because you’ve already aligned closer to their expectations.
So, yes, that’s a key takeaway: understanding your reviewers is incredibly important.
Beyond code reviews, I was assigned my first project collaborating with a senior engineer who was also relatively new to the team. We were both learning a lot. Another team member had been there longer and helped guide us. It was a fantastic experience. The senior engineer gave me plenty of space to lead the coding work, mostly handling external communication and coordination, while I focused on writing the code and ensuring everything ran smoothly.
For the second project, he was still assigned with me but was much more hands-off. I essentially had full ownership – writing the design docs and executing the implementation. It was incredibly fun figuring out the problems and finding solutions.
Throughout all this, I regularly checked in with my manager about my progress. At one point, they simply suggested, “You’re writing design docs, you seem ready for the next level. You should apply for promotion.”
I did, and it went through! I got promoted within my first year and have been at the next level for about six months now. Honestly, it doesn’t feel drastically different. The main change is that I’m no longer in the onboarding phase; I know the systems and, more importantly, the people.
Regarding people, it’s probably the topic whose impact on the work I most underestimated. How much difference do diverse personalities and approaches make within a team? A lot. Different people handle problems differently, and communicating effectively with each person often requires a distinct approach.
Some colleagues prefer you to cut straight to the chase: “Here’s the problem, here’s the solution.” Others really want to understand the problem deeply first and explore potential paths together before hearing a proposed solution.
Honestly, it can sometimes be challenging to fully grasp how certain people think or “tick.” But I’m working on getting better at it. Reading people is an extremely valuable skill. I didn’t arrive with the expectation that it would be so central to the job, but it truly is.