Imperial College of Science,

Technology and Medicine

Department of Computing
MEng Joint Mathematics and Computing

Industrial Placement Report

Google Zürich

Author: Managers:
Andrei-Bogdan Puiu Manuel Ferreria,
ap8415 Agnieszka Pachuta
CID: Imperial College Tutor:
01063065 Dr. Fariba Sadri
Contents
1 Company Overview 2

2 Team Overview 3
2.1 Google Ads . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 My team - AdWords for Video EngProd . . . . . . . . . . . . 3

3 Project Description 4
3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Dapper . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2 Our product . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Project Management 6
4.1 My Work and Contribution . . . . . . . . . . . . . . . . . . . 6
4.2 Project timeline . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5 DoC Courses 8
5.1 Software Engineering Design . . . . . . . . . . . . . . . . . . . 8
5.2 Pintos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3 Object Oriented Programming . . . . . . . . . . . . . . . . . . 8

6 Placement Benefits 9

7 Ethical and Professional Issues 10

7.1 Respect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 Competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.4 Environmental . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

8 Conclusion 11

References 12

Appendices 13

A Manager approval 13

1
1 Company Overview
Google is an American multinational technology company which focuses on
Internet-related services and products. It is one of the most well-known com-
panies in the world. Its core, and most ubiquitous, product is Google Search,
but the company also has market-leading offerings in many domains. It is
almost impossible nowadays to go one day without using a Google product,
such is the impressively vast array of areas in which Google has interest.

Google began in January 1996 as a research project by Larry Page and Sergey
Brin, back when they were both PhD students at Stanford University in Stan-
ford, California. They developed a new system for analyzing relationships
between websites, called PageRank, and used it to create a new search en-
gine. Initially called ”BackRub”, because the system checked backlinks to
estimate the importance of a site, it was eventually changed to Google. The
company itself was incorporated a bit over 20 years ago, on 4 September 1998.

The company’s rapid growth since its incorporation in 2004, driven by its
highly successful advertising model, has led to the development of a large
suite of products, as well as a number of technological acquisitions. Nowa-
days, Google offers solutions in domains such as video sharing (YouTube),
cloud storage (Google Drive), mobile operating systems (Android), Internet
browsers (Chrome), language translation (Google Translate) and many more.

2
2 Team Overview
2.1 Google Ads
Google Ads (previously Google AdWords) is an
online advertising platform developed by Google,
where advertisers pay to display brief
advertisements, service offerings, product listings,
video content and generate mobile application
installs within the Google ad network to web users.

Google Ads has evolved into Google’s main source of

revenue, contributing to Google’s total advertising
revenues of USD $95.4 billion in 2017 (add reference
from wiki).

2.2 My team - AdWords for Video EngProd

The AdWords for Video team works on the video ads part of Google’s ad-
vertising model (namely, the ads shown on YouTube videos).

My team was a subsection of this team dedicated to engineering produc-

tivity. Its goal is to provide internal solutions to make life easier for other
software engineers working in AdWords. In my time at Google, the team
consisted of 8 engineers, one of which was my initial manager Agniezska, as
well as 3 more interns including myself.

Mid-internship, Manuel became my new manager, but I remained part of

the initial team and worked on the same project.

3
3 Project Description
3.1 Background
3.1.1 Dapper
Google services are mostly implemented as complex, large-scale distributed
systems. These applications are constructed from collections of software
modules that are developed by different teams, perhaps in different program-
ming languages, and could span many thousands of machines across multiple
physical facilities, all interacting with each other.

A tool to aid in understanding how these interactions happen, in order to

measure their performance and correctness, is therefore invaluable in a com-
pany of Google’s size. For this purpose, Google researchers developed a
distributed tracing infrastructure called Dapper.

Dapper groups inter-process communications into traces, and associates to

each trace a unique 64-bit number, called trace ID. My team’s product
leverages this trace ID mechanism to achieve its goals, as described below.

3.1.2 Our product

At Google, quality checks are of the utmost importance. In order to be able
to create a new release of a product which serves users, either a front-facing
one like Search or a backend product like a database, it needs to be fully
tested to minimize the possiblity of issues. While unit tests are highly valu-
able, for these kind of systems we also need large-scale integration tests. For
these, it is desirable to test as close to production conditions as possible (QA
testing); this would generally mean manual testing.

My team’s product allows teams to also create automated integration tests

which run in a near-production environment. To do this, it uses a system of
proxies which can be configured to route requests to a backend of the user’s
choosing.

The proxy uses the trace ID of a request to determine the backend to which
to redirect it. A team which wishes to test a new release of its product can,
as part of its integration test, instruct the proxy to re-direct traffic from a

4
particular trace ID from its production system to its system under test, and
then associate that trace ID to the artificially-generated requests of that test.

3.2 Motivation
Our product was adopted by a lot of teams inside Google. This created
concerns in terms of scalability and extension:

• There was no way of monitoring what happened to the requests which

went through our proxies

• We didn’t know how much traffic our proxies served

• When adding a new proxy to the system, we couldn’t ensure it was

configured correctly

3.3 Solution
This led to a need for creation of a system which could gather data about
the proxies, and monitor what was happening. My project was to design and
build such a system.

The system has two major components: data gathering and data vi-
sualization.

To gather the data, the proxies were made to record the requests going
through them, and generate several data points which were considered use-
ful, namely for data per-proxy and per-test (with each test identified by a
trace ID).

This data was then stored to an internal database, and various charts and
tables were generated from it and displayed in a dashboard.

Since each team wants to know about its own proxies, the project was de-
signed to be able to produce systems which work independently from one
another, for each team’s proxies.

5
4 Project Management
4.1 My Work and Contribution
For the 4 months of my internship, I worked solely on this project, under my
two managers. I was given full ownership of the project, along with a set of
objectives I was expected to achieve during the internship.

All the changes to the Google codebase related to the project were made
by myself. Every contribution was then subjected to a code review process,
where usually at least 2 other engineers ensured my code met quality stan-
dards. One of them was usually my manager, while another ensured that the
code adhered to language-specific standards (known as a readability reviewer.

In the design process, all the main choices were made by me. I also drew
upon the initial project proposal from Agnieszka for ideas, and consulted
with my managers for feedback, either directly or in our weekly scheduled
one-on-one meetings, to ensure product quality and that no bad choices were
made, or good options overlooked.

4.2 Project timeline

• Introductory phase (weeks 1-2): new tools, new codebase

As I had previously worked at Google, I already had a decent level

of familiarity with the generalities of the company.
I spent most of this time familiarizing myself with the goals of the
project, the codebase with which I was going to work with, as well as
some of the internal tools which I would want to use for my project
(examples: Monarch, Dapper)

• Design phase (weeks 2-4)

I analyzed the main design choices for the project, analyzing the pros
and cons of each possible approach. I discussed these with the engineers
close to the project, and decided on the most appropriate solutions.

• Feature implementation phase (weeks 4-16)

6
 I had 4 main high-level goals to achieve: data for proxies, data for
tests, infrastructure, and integration with Google’s testing systems.

Each of these goals roughly translated to a single feature, which was

implemented in around 2-4 weeks, depending on the complexity of the
feature and the engineering challenges encountered.

For each feature, there were also extensive unit tests added to ensure
the stability and correctness of the code.

• Running in production (weeks 14-16)

I set up the components of my project to run on Borg, Google’s job

running system.

• Documentation (gathered across the project; design doc written in

weeks 8, 16-17)

All the work was carefully documented, so that the design and im-
plementation were easy to decipher for any engineers who wanted to
maintain or extend my project, or simply to understand it.

In addition, as mentioned in the ’Solution’ section, the project allowed

each team to have its own monitoring system; in the documentation, I
added instructions on how to create a system for your team.

• Presentation (week 17)

At the end, I gave a presentation of my summer’s work to engineers

that were on my team or had an interest in my project.

7
5 DoC Courses
In my three years of undergraduate education at Imperial College, I became
a very capable engineer capable of working at the same level as my more
experienced work colleagues. I felt that the DoC courses and projects had
a big impact on my development and skill set. I mention a few of the most
important ones to me that helped me throughout my internship.

5.1 Software Engineering Design

In Software Engineering Design I learned the value of well-written software
in terms of how it helps reduce the effort of future engineers to understand
it and improve it. It taught me many valuable patterns to apply in my soft-
ware to improve performance and usability. Last but not least, it showed me
how to do unit testing and why it is so valuable, which proved immensely
beneficial at my work place.

For me, all of these things made this course extremely valuable, and helped
bridge the gap from programmer to software engineer.

5.2 Pintos
Pintos was the first project I worked on in which I didn’t start from scratch.
As a result, I developed the ability to quickly understand large codebases,
which helped me navigate through the immense amount of code at Google.

Another aspect in which Pintos was valuable to me was the low-level as-
pects of it, which improved my understanding of programming as a whole.

Finally, the difficulty and tight time frames helped me improve my speed
of coming up with, and coding, solutions to intricate problems.

5.3 Object Oriented Programming

The course taught in the first year has proved to be crucial in understanding
the main concepts of object-oriented programming; as most languages nowa-
days (including the ones I used this summer) make use of this programming

8
paradigm, it’s an invaluable skill to have. In addition, its focus on Java made
it one of the languages I am most proficient in.

6 Placement Benefits
When I applied to Imperial’s JMC program back in 2014, one of the main
points of attraction for me was the industrial placement experience. I felt
that working for 4 months in my field before graduation would be extremely
beneficial for me, and aid me substantially in my progress towards becoming
a software engineer. Having now finished my placement, my belief has only
strengthened that the experience is one of the most valuable in the degree.

I was exposed to various aspects of working in a top-end tech company,

of which I name only a few here:

• Code is always subject to review, from multiple persons (I’ve personally

had reviews from as many as 5 other engineers on a code change)

• There are standards for each programming language used, and some-
times team-specific standards too

• Unit-testing is a requirement; code without unit tests will never be

approved.

• There is a large existing codebase, along with a lot of internal tools,

which all need to be understood before delving in.

I also gained a sense of how to work as part of a large team, and collaborating
with an even larger set of people. While at Imperial the projects were geared
towards working on the same project in a small team, in the workplace the
situation was different. The role of my teammates wasn’t necessarily to in-
tervene in my work, but rather to help me build my understanding of things,
and make sure that my project was of a high quality.

In the end, this also meant that ownership of what I built, both in suc-
cess and failure, was mine, which gave me a sense of responsibility in which
I thrived. I was able to take control of the design process, and build all of
the features myself from the ground up.

9
I also learned how to deal with the 5-day working schedule; as while in
university one can usually pick and choose when to be more involved and
when not to be, at Google I needed to fulfill my work obligations, and spend
at least 8 hours every day working. Unlike most companies though, Google
was quite flexible about how those hours were worked, which allowed me to
tailor my schedule to create a balance between my work obligations and my
personal life.

7 Ethical and Professional Issues

7.1 Respect
One of Google’s core values is to respect every one of your peers, regardless
of background, age, nationality and so on - captured in the motto, ’Don’t
Be Evil’. I felt valued by everyone around me, and was treated with respect,
kindness and understanding. I felt a sense of belonging, and it made me want
to come back to Google in the future.

7.2 Competence
In the first few weeks of being employed at Google, there are many talks that
introduce the newly-employed into company culture and practices. Also, sev-
eral trainings on issues such as privacy and confidentiality are compulsory.
At team-level, the manager instructs a new employee in order to familiarize
with the project, the team and the codebase.

Beyond that, at company-level, Google offers a wide range of courses, to

ensure that employees can obtain any skills they may be lacking. There are
tons of internal resources for self-study. And of course, the people around
you are very willing to share, and are a valuable source of information and
aid.

7.3 Integrity
At Google, honesty and integrity are highly-prized values. Everyone is open
to receiving feedback, even if negative, as long as it’s delivered with positive
intentions; employees are encouraged to speak up, including to higher-ups,

10
without any fear of retribution. It’s also common practice to credit all the
people who aided in developing a project. In my case, I made heavy use
of the work of another engineer, and also contributed to his work myself; I
made sure to give him the appropiate credit.

7.4 Environmental
Google highly values being eco-friendly. Recycling containers for all the main
types of waste are placed all over the workplace (at least 2-3 of each per floor),
and all of us are encouraged to try and recycle all our waste. Google min-
imises paper waste, by having a fully paperless system for administrative
issues, and not using any sort of paper containers. Most of the rooms have
motion detectors so that the lights are only when needed, and a similar sys-
tem is used in the bathrooms to save water.

In addition to the company-level efforts, Google also undertakes eco-friendly

initiatives, such as powering all its data centers with purely renewable energy

8 Conclusion
The placement at Google Zürich was an immensely valuable experience. It
gave me the sense of what it is like to work in industry, and I can say it has
prepared me for making the step to full-time employment.

11
References
[1] Google Wikipedia
https://en.wikipedia.org/wiki/AdWords

[2] Google Ads Wikipedia

https://sustainability.google/projects/announcement-100/

[3] Dapper, a Large-Scale Distributed Systems Tracing Infrastructure

https://ai.google/research/pubs/pub36356

[4] Monarch, Google’s Planet Scale Monitoring Infrastructure - Roberto Lupi

- Codemotion Milan 2016
https://www.youtube.com/watch?v=LlvJdK1xsl4

[5] Large-scale cluster management at Google with Borg

https://ai.google/research/pubs/pub43438

[6] 100% renewable is just the beginning

https://sustainability.google/projects/announcement-100/

12
Appendices
A Manager approval

13