My first impressions working at Google as a Software Engineer
I joined Google in Canada as a Software Engineer three months ago! I’m sure that many people are curious about how working here feels like, just as I was before I started. The experience has been amazing so far! So, I can share my initial impressions as a Noogler (short for “New Googler” — that’s how they generally call those who joined the company in their first six months).
I’m working in the Chat API team, which is one of the teams expanding the Google Workspace functionalities. We are working to improve how enterprise applications can extend and integrate with Google Chat so users will be able to interact with their applications and workflows directly from Chat. I have the opportunity to work on interesting engineering tasks, helping improve products that are used by millions of people, in an environment that is made to help people feel comfortable while they do their job!
General Impressions
Great Information Management
There is a lot you need to learn in your first weeks, about many different topics, such as HR policies, company culture, team structure, offices and facilities, engineering practices, internal tools, and so much more. But I was impressed with the amount and quality of the information provided in the internal documents. There are official documents (such as policies), specific documentation provided by the team responsible for the information (such as technical guides about each specific tool), an internal discussion forum, and other information sources. And to help navigate all that, there is an internal search tool (kind of a Google for Googlers), which really helps with finding what you’re looking for. There was also no shortage of people in my team that I could ask when I could not find the answers, but more often than not, I was able to find my way on my own using the internal search tool and the available documentation. For a company whose mission is to “organize the world’s information and make it universally accessible and useful”, it’s great to see that they are really good at managing their own internal information.
Initial Training
You generally need to go through several training sessions when you join a new company, especially a large one. It’s no different at Google. I went through two kinds of training: the Noogler Orientation, which provided general information about the company, its mission, culture and general procedures, and the Technical Immersion, which provided information about the Engineering tools and practices. All sessions were virtual (although I suppose they will go back to having in-person sessions at some point in the future), with some pre-recorded videos or reading materials, and a few with synchronous video conferencing. During the Technical Immersion, each Noogler also works on an introductory project, which helps them get used to the codebase and tools. Even though it was an intense training week, I had a great experience! I felt that all the information presented was interesting and most of it was directly useful for me. Even the bits that were not directly applicable at the moment were quite interesting.
Inclusion, Ethics, and Privacy
In general, Google seems to have a great concern in being inclusive and ethical. That’s something that is really emphasized in employee training. There is a focus in building applications that can be used by anyone in the world, and a lot of care in dealing with user data. Everything that is designed is thoroughly reviewed for ethical, security, or privacy issues. Regarding privacy, logically, we all know that Google serves personalized ads for free users based on their data, and it is something that users have to agree to in case they want to use the free products. But there are strict rules that prohibit using user data for anything else or sharing it with anyone else. Of course, I just joined the company and cannot say much about how everything is executed except for the first impression I had from training and first tasks, and it was a generally good impression.
Hybrid Working
Currently, Google has been quite flexible regarding how people prefer to work (in the office or at home), although most employees have been invited to adopt at least a hybrid work week. I have decided to go hybrid and work three days at the office and two at home each week, balancing focused and productive days at home with days to collaborate with my team in the office. Something that I think my team is doing well (may not be the same for all teams) is scheduling meetings on the days when most people are in the office (Tuesdays, Wednesdays, and Thursdays), and trying to leave Mondays and Fridays open so people can focus on their tasks without interruptions. I have seen a healthy concern for good work/life balance during this time. The guidelines encourage everyone to build sustainable work habits and not try to “be a hero” by overworking oneself to get things done.
I will also comment on the availability of free food in the office as it is something that I see everyone talk about. 😀 I feel it’s an interesting experience because it makes my day easier, I can focus on doing my job and don’t need to worry about what/where I will eat. If I’m hungry during the day, I can just grab something in one of the micro kitchens in the building and get back to work, which is much more efficient than for example having to leave the office to buy food elsewhere. So, it’s not the fact that it’s free food that is good (after all, I would be able to afford food for myself if it was not free), but it’s a great perk for its convenience as it allows me to focus more on my job during the day.
Technical Impressions
It is very interesting to work as an Engineer at Google because there is a large focus on building clean, well documented, readable, and maintainable code. This is essential when there is a huge codebase with thousands of Engineers working on it. The general guideline is to take the time to write clean code that is well documented and tested, rather than quickly making it work in detriment to everything else. Every line of code that goes into the repository needs to be reviewed by someone else, not only for correctness, but also for how readable and maintainable it is. As a result, looking at existing code to learn how it works and maintain it has been generally a good experience so far.
On the other hand, there are logically more procedures and processes than in smaller companies, which is to be expected. Any new features need to have its design properly documented and approved before it’s built. And before launching it, there are new rounds of documented tests and approvals for security, privacy, and site reliability. Although this surely makes launching new features slower than in smaller and nimbler companies, I understand that it is essential for a company this size. Any change in one of Google’s products can potentially affect millions of people in a short period of time, therefore, it is essential that every launch is properly reviewed and planned for.
Additionally, there is a general culture of transparency and collaboration that is very refreshing. Most internal documents and code are available for everyone to look at, except for specific things that need to be more restricted. Everyone is encouraged to ask questions and give suggestions as needed, as well as be proactive in helping improve the codebase. That means that if you notice something that needs to be fixed in another part of the code, you’re encouraged to suggest a fix yourself or at least report it to the team that owns that feature.
Infrastructure and Tools
The internal infrastructure and tooling that exists to support developers is quite impressive. Most of the tools are built internally because the size and complexity of the codebase easily surpasses what existing tools are capable of dealing with. I was impressed to learn that most of the code is on a single, huge, customized monorepo, with an integrated build tool that is capable of resolving dependencies within the repository and building any code in any of the supported languages. There are also integrated tools for bug tracking, code reviews, automated tests, and almost anything that you may need as an Engineer.
Development Frameworks
In addition to the tools, there are also several frameworks developed internally to do most of the things that you need as a developer, such as handling Web/RPC requests, dependency injection, unit/integration tests, and more. Although it was a lot to learn in the first weeks, I was happy to realize that it was not too hard because the engineering concepts behind them are similar (e.g, dependency injection, unit tests, etc.). So, I just had to apply the knowledge I had to learn the specifics of each new framework. Logically, it takes a bit of time to ramp up productivity, but I feel it did not take too much for me.
All in all, I’m enjoying this opportunity immensely! Getting here has been a long journey for me, but it has been worth it! Feel free to comment if you have questions!
