## The Question

How much storage space do you need to store all the information from Google maps?

## Answer Structure

In estimation questions, interviewers are evaluating your problem-solving and quantitative skills. They are looking for a ballpark number, not an accurate number. What matters is whether you are logical, can explain all your assumptions clearly, are organized in your work, and good with numbers.

The book *Cracking the PM Interview* by Gayle Laakmann McDowell and Jackie Bavaro provides a good suggestion on how to structure an answer for this type of question. It can be summarized as:

**Ask clarifying questions**. This will eliminate any ambiguity of what should be included in your calculations.**Make an equation**. Consider edge cases or alternate sources of data and write down any facts that you know will help with calculations.**Break down the equation into components**. Write down any assumptions next to the components so you don’t forget to explain them clearly to the interviewer.**Do the math**. Calculate the result of each component and compute the result.**Do a sanity check**. Do your results make sense? If not, recheck your equation, assumptions and arithmetic.

## Answer Example

**INTERVIEWEE**: Is this estimation for the US alone or the world?

**INTERVIEWER**: For the world.

**INTERVIEWEE**: Okay. Based on my experience with Google maps, it provides information about:

- Street names
- Homes
- Public buildings
- Businesses
- Traffic
- Non-urban areas, like mountainous terrains

**INTERVIEWER**: Okay, good, but why are you differentiating between homes, public buildings and businesses?

**INTERVIEWEE**: I have seen that Google maps displays more photos for buildings and business locations than for homes. Therefore, public buildings and businesses will require more storage than homes and I need to treat them separately.

**INTERVIEWER**: ok, agreed.

**INTERVIEWEE**: Here is how I would estimate storage for each of these categories.

Street names storage:

[# cities] X [# streets/city] X [storage for street name]

Homes storage:

[# cities] X [# homes/city] X [one photo storage + text storage]

Public buildings storage:

[# cities] X [# public buildings/city] X [10 X one photo storage + text storage]

Businesses storage:

[# cities] X [# businesses/city] X [10 X one photo storage + text storage]

Traffic storage:

[# streets] X [storage/minute] X [# minutes/year]

Non-urban areas:

[surface of the earth in square miles] X [25%] X [storage/100 sq miles]

Total storage

= [Street names storage]

- [Homes storage]
- [Public buildings storage]
- [Businesses storage]
- [Traffic storage]
- [Non-urban areas]

To estimate the storage required for street names, homes, public buildings and businesses, I will differentiate between large and small cities, because big cities have more of these types of locations than small cities.

For traffic storage estimation, I will assume that traffic information is kept only for a year.

Okay, let me start with the big city calculations:

### Big city streets calculation

I will use New York city as a proxy for a big city. It has about 1000 streets, and assuming it takes 100 KB to store the street name and other metadata, like its distance, then it takes 100 MB for a big city to store street information. I am not including photos of the street, because I will account for the street photos in the homes, public buildings and businesses storage calculations.

### Big city homes calculation

For the big city homes calculation, New York city has about 9M people, and assuming there are 3 people per home, that gives 1M homes. Then assuming 4 MB for a photo of the street view and 100 KB for the home location information, and multiplying by 1M homes results in about 12 TB.

### Big city public buildings calculation

Assuming there are about 10,000 public buildings in a big city, multiplying that by (40 MB + 100 KB) which is storage for photos and text, results in 400 GB. I am assuming that there are about 4x as many photos for buildings than for homes.

### Big city businesses calculation

Assuming there are about 20,000 businesses in a big city, multiplying that by (40 MB + 100 KB) for photo and text storage results in 800 GB.

Let’s move to small city calculations:

### Small city streets calculation

I will assume that the number of a streets in a small city is about 1/4 of the number of streets in a big city, so 1,000 / 4 = 250. Multiplying this number of streets by 100 KB to store the street metadata results in 25 MB.

### Small city homes calculation

I will assume that an average of 300,000 people live in a small city. Divide by 3 persons per home, gives 100,000 homes. And multiplying that by (4 MB + 100 KB) for photo and location storage, results in 410 GB.

### Small city public buildings calculation

I will assume the number of public buildings is 1/10 of the number of buildings in a big city, so 10,000 / 10 = 1,000 buildings. Multiplying that by (40 MB + 100 KB) of storage for photos and text, results in 40 GB.

### Small city businesses calculation

I will assume the number of businesses is 1/4 of the number in a big city, so 20,000 / 4 = 5,000. Multiplying that by (40 MB + 100 KB) of storage for photos and text results in 200 GB.

With these results, I can now calculate the total storage for one big city as 100 MB + 12 TB + 400 GB + 800 GB = 13 TB. And, the total storage for a small city is 25 MB + 410 GB + 40 GB + 200 GB = 650 GB. Now we need to multiply these numbers by the number of big cities and small cities. I know there are about 1,000 big cities in the world and I am going to guess that there are about 4,000 small cities, so the total storage for city information in Google maps is: 1,000 X 13 TB + 4,000 X 650 GB, which is about 15 PB.

Let’s calculate traffic data stored in Google maps. I will assume that traffic data is only kept for one day. Under this assumption, I will estimate storage by multiplying the number of streets in the world times storage needed to record traffic per minute times minutes in a day. To calculate the number of streets, I will first estimate the number of streets in big cities and then small cities. I know there are about 1000 big cities in the world and I will assume that a big city, like New York City, has 1000 streets, so 2,000 x 1,000 results in 2M streets for big cities. Assuming there are 4,000 small cities in the world, and that each small city has about 250 streets, then there are 4,000 X 250 = 1M streets for all small cities. Then multiplying the number of streets by the storage per minute and minutes in a day gives (1M + 1M ) X 10 MB / minute X 1,440 minutes / day, resulting in 28 PB. I am assuming here that it takes 10 MB per minute to record traffic photos per street.

Now let’s calculate non-urban areas. I will use the surface area of the earth to do this. The surface area of the earth is about 4 x π x radius², where the radius of the earth is about 4000 miles. Assuming that 25% of the earth surface is solid, and to store metadata takes 400 MB per 100 sq. miles, the equation becomes 4 x 4 x (4,000 miles)^2 X ¼ X 400 MB / 100 sq miles = 256 TB.

Finally, adding storage for cities, traffic, and non-urban areas results in 15 PB + 28 PB + 256 TB = 43 PB. Google holds about 15 EB per year, so I think that 43 PB for Google Maps is not unreasonable.