My Google Internship Project
What I Did As a Google Intern
Hi everyone ! Thanks for all the positive feedback on my first blog series 😊 One question I got from a reader was around the technical work you do as an engineer at Google. Obviously I was only an intern, so I can only speak on that experience, but this post will hopefully provide some insight into what my project involved and the process I followed. For some context, I worked on a feature for a new application (which I'll refer to as KG) under the Google Photos ecosystem. Unfortunately, this app is still in the beta phase, so I'm not able to speak on specific **details- although that shouldn't affect this write-up too much.
Project Background
In KG, user's can share photos to other users on the platform as 'posts'. To help the authors of these posts measure engagement, we wanted to give them the ability to see who has opened and viewed their posts. This feature is similar to what you would find in other social media apps like WhatsApp or Messenger. Also, by collecting this information, it would provide useful analytics for the team to measure metrics like user engagement (i.e. what's the average number of user's that are expected to interact with a shared post). This feature was entirely new to the application, so my project involved designing, implementing, testing and deploying the entire feature.
Planning
For those that don't know, a big part of Google's engineering culture are design documents (DD's). A DD is a document (ranging from one or more pages) that needs to be created for each feature, describing its purpose and implementation details. It also describes the different alternatives considered, and the reasons why they were foregone. They serve the purpose of making sure engineers consider all the possible solutions to a problem, rather than just diving into coding straight away. Additionally, it's likely that a feature you created will be maintained by someone that's not you in the future, so it's important for them to understand the thought process behind the design decisions you made.
Although Google probably stresses DD's the most. It's a pretty common practice at most big tech companies. So written communication is a super important skill to practice while at university.
I was pretty shocked when my manager first introduced the project to me and basically said okay now go come up with a design- enjoy ! On top of that, I was expected to present my design to the entire team and try convince them that whatever I come up with is the best solution. I can't front, I was pretty scared that I was leading this task on my own, but I was also pretty excited with the amount of responsibility I was given. Fortunately, my entire team was super supportive and told me that I could just schedule a meeting in their calendars anytime if I ever needed anything from them. Also, I had the help from a wealth of internal resources- ranging from shared code repositories to the DD's created by my team for other features.
The first two weeks of my internships involved no coding, and was a frantic scramble to learn as much about the existing systems as possible so I could write my DD. I scheduled a 30 minute meeting with each team lead (Android, IOS, Backend, Frontend, UI/UX) as my feature would span across all teams. Because our application integrates with the main Google Photos backend, I also had the opportunity to collaborate with some engineers from the MTV (Google HQ) office. From these conversations, I got a small peek into the sheer complexity of managing billion-user product like Google Photos. I was able to also see how a similar 'photo viewing' feature was implemented for the main Google Photos app. Even a simple counter tracking how many views a photo had involved distributed systems, database sharding and countless other engineering feats.
Not gonna lie, the first iteration of my DD got ripped to shreds during the initial review session. But, the entire team was super engaged with my project, and everyone offered ideas and suggestions for improvements. After almost a week of back and forth iterations, I finally landed on a design that I was proud of. Honestly, you'd be surprised at how long these things can take. I'd written similar documents for my software architecture course at uni, but its way different when your designing something that's actually real and needs to work. There were also other areas like privacy that I've never even considered before. What happens when a user deletes their account ? We want to keep the view count for any posts they've viewed unchanged, but we can't associate their account with the view anymore. Factors like this ended up even ended up influencing the database schema.
Implementation
I'll try not bore you with too many technical details, but the backend stack for my project was primarily Java combined with a bunch of Google specific frameworks. These included Spanner (a relational database) that's also available for external use (https://cloud.google.com/spanner), a Google ORM, asynchronous queues and an internal microservice platform which everything is run on. The front end was your standard HTML/CSS/JavaScript stack combined with a weird templating language (think EJS or Handlebars) that I never really fully understood, but somehow flailed my way through. Picking up most of these technologies was quite straightforward, as most resembled some popular (non-Google) alternative I had already used before. Also, every technology had its own dedicated wiki page, that has everything you ever need to know.
Being completely honest, I don't think the implementation for my project was that technically difficult. All the logic that handles when a user viewed a photo already existed in the main Google Photos backend. (In a very simplified sense) All I had to do was hook our app into a subscriptions module provided by Google Photos and listen for updates. This data was fed into some asynchronous queues, which KG's backend then collects. The bulk of the project involved coding the logic in our backend that processes these views, and storing them into our database. I also had to handle various edge cases. As the queues are asynchronous, there's a built in retry mechanism that can lead to the same message (containing viewed photos) being put into the queue multiple times. These duplicates had to be filtered out to ensure the views were accurate.
When I did get stuck on this project, I felt it was mostly due to me trying to understand how one of our internal tools worked, or how an existing system I had to interact with functions- rather than 'hmm, I wonder what the best way of implementing this is'. Examples include things like finding how to mock a dependency with the internal testing framework l o l. Another (more tricky) thing I discovered was that the concept of a 'post' only exists in the KG world, and that Google Photos makes no distinction on their backend. Once I figured that out, I had to write a small translation service to map the set of viewed photos Google Photos sends us, into their corresponding posts. This task was necessary as we wanted to record views on a per-post basis, rather than per-photo basis. Once again, not a technically challenging task, but one that required me to understand how all these systems work.
Closing Thoughts
All in all, I really enjoyed my project, and it was cool completing an entire feature on my own. Deploying my code and seeing it work was probably one of the most rewarding feelings during my software engineering career so far. I'm also super thankful for having incredible intern hosts, who paced my project well and ensured that I had all the support I needed. So what are the next steps then? I think one of the biggest takeaways from my internship is understanding how big this company actually is. From all the interns I talked with, it seemed like they each had a completely unique experience with their projects. From me working on a start up with less than 1000 users, to someone else working on AR for a billion user product and another working on car software? Our teams could totally be completely separate companies.
Being completely honest, I'm still not sure what type of project or team I'm looking for. I think after grinding out so many shitty projects for uni, I'm just super tired of CRUD based web-apps. I don't really know how to explain it, but this type of software development just feels super one dimensional at times. Many web-apps these days are so similar, maybe the domain changes, but all the logic is practically the same. I know this is a gross oversimplification, but every new feature you create seems like create some API to store some data in the database, create another API to retrieve this data, write some UI code to display the data. Rinse and repeat until stakeholders are happy. I've been told that the interesting challenges come once you start dealing with scale, but because I was working on a start up project, I didn't get to experience that for myself.
So I guess that's the challenge im seeking out next. I want to see what new fun and interesting problems a million user product brings. Other areas that have piqued my interest are projects involving a strong algorithmic side. Stuff that needs to be fast. I've also recently been looking at work around infrastructure engineering and distributed systems. Honestly, at times, I get pretty stressed out that I haven't found an area in software that's really clicked with me yet. But at the end of the day, I need to remind myself that it's okay. I think a lot of us are always in go, go, go mode, but its important to know that this isn't a race, and that it's okay to just chill out and enjoy the journey. Anyways, I hope you like the post (even though the last section is all over the place) and it gave you a perspective into what working at these big tech companies can look like. Take care.
If you've got any questions, criticisms, thoughts or ideas, feel free to reach out to me @ andrew.h318@hotmail.co.nz (I will try fix the contact form soon LOL).