🦥 How Does Google Maps Find The Fastest Route?

Hello friends!

Welcome to this week’s Sloth Bytes. I hope you had an amazing week!

Why is every tech company switching to this app?

Teams at Vercel, Brex, Replit, Linear, Ramp, and Intercom all use it. Brex is saving 427 hours a week with it. And Vercel's CEO said there's no going back.

It's called Granola, so when I heard all these companies were using it, I had to try it.

Granola records your meetings automatically and transcribes everything in the background while you take notes like normal. No bot joining your call, no “recording in progress” sound, nobody knows it's there.

After the meeting, it takes your notes and the full transcript and turns them into a clear summary of the meeting and what you actually need to do next.  Granola also has templates so you can get different summaries depending on the meeting.  Plus, you can chat with it after and ask questions about the meeting.

Oh, and you can share that summary with your team. Because let's be honest, they forgot too.

Try Granola on your next meeting. Free for a month with code CODINGSLOTH.

How Does Google Maps Find The Fastest Route?

You know, I’ve never once stopped to ask how Google Maps comes up with the estimated time. I just see that it takes a few minutes and follow the route like the good boy I am.

But apparently, every single time you pick a destination, Google Maps is solving a genuinely hard math problem. Across millions of roads. Millions of intersections. Real-time traffic conditions. Your preferences. Toll roads. One-way streets.

In milliseconds.

All thanks to decades of computer science, graph theory, and of course AI.

Let me explain how sick Google Maps is and why it’s one of the best technologies ever.

How Google Maps picks a route

Before we get into the cool algorithms, we need to talk about how Google Maps sees the world.

As you all know, computers don’t have eyeballs like us, so they need a different way to “see.”

For google maps, it doesn't see a map, roads or cities.

It sees a graph (it’s a cool data structure that every programmer should know.)

Every location = a node. 

Every road connecting to the location = an edge. 

Every edge has a weight = the estimated travel time.

What the heck is a weight?

When a graph has a weight, it’s called a weighted graph (crazy name I know), and a weight is usually just a number.

The lower the weight, the better it is.

For google maps, that number is determined through a lot of information:

• road surface (paved vs. unpacked dirt)

• turn difficulty

• toll costs

• speed limits

• one-way restrictions

• ferry crossings

• your personal preferences like "avoid highways.

Basically google maps tries to find the most convenient route.

So "find me the fastest route from A to B" becomes:

Find the path through this giant graph with the lowest total weight.

Sounds simple right? Well the idea is simple, the hard part is the terrifying scale.

The algorithm that made this idea possible

It's 1956 in Amsterdam. A Dutch programmer named Edsger Dijkstra is out shopping with his fiancée. They get tired. They sit down at a café.

No laptop. No notebook. No pencil.

Just a really smart guy thinking: What is the shortest way to travel from Rotterdam to Groningen?

And in 20 minutes, he designs one of the most important algorithms in computer science history.

All in his head btw.

We call it Dijkstra's Algorithm.

70 years later, it’s still at the heart of how Google Maps works today.

What a productive coffee break.

Dijkstra’s Algorithm

Here's how it works:

1. Start at your origin node (starting point). Assign it a cost/weight of 0.

2. Assign every other node a cost/weight of infinity since you haven't found a path there yet.

3. Look at all your current node's neighbors.

4. Update their costs if you found a cheaper way to reach them.

5. Move to the unvisited node with the lowest cost.

6. Repeat steps 3-5.

7. Stop when you hit the destination.

This website is great at showing you how it works visually.

This algorithm guarantees the shortest path every time.

Sounds a bit complicated (especially if you don’t know graphs), but it’s honestly something we usually do without even thinking.

You don't take random roads home, you take the ones that feel most promising. Dijkstra just turned that instinct into an algorithm.

Here's what that looks like in code:

import heapq

def dijkstra(graph, start, end):
    # Priority queue: (cost, node)
    queue = [(0, start)]
    visited = {}

    while queue:
        cost, node = heapq.heappop(queue)

        if node in visited:
            continue
        visited[node] = cost

        if node == end:
            return cost

        for neighbor, weight in graph[node].items():
            if neighbor not in visited:
                heapq.heappush(queue, (cost + weight, neighbor))

    return float('inf')  # No path found

One problem though. It doesn't scale.

The scale problem

There are millions of homes, restaurants, streets, sideways, etc.

If you run Dijkstra on that from scratch every time someone searches for a route, depending on the distance, it would check thousands to even millions of possible routes. This could take seconds or even minutes.

For Google, seconds aren’t fast enough, it needs answers in milliseconds.

So they layer two optimizations on top of Dijkstra’s.

1. A* (A-Star) Search

Dijkstra explores every direction equally because it has no idea if we’re actually getting closer to the destination.

This is why they use the A*(A-star) algorithm.

This algorithm use’s Dijkstra’s and optimizes it by adding a heuristic. Which is basically an educated guess about which direction to prioritize.

For routing, the heuristic would be: how close does this path get me to the destination?

A*'s heuristic just needs to never overestimate the true distance to stay optimal. This property is called being admissible, and it's the theoretical reason A* still finds the correct shortest path despite skipping nodes.

Think of Dijkstra as checking every possible route while A* looks at all routes that bring us closer to our destination.

Same guaranteed result, but takes way less time.

2. Contraction Hierarchies

This is where it gets big brain.

When you're driving from city to city, you'll spend maybe 2% of your time on side streets. The other 98%? Highways.

So why should the algorithm waste time evaluating every small street?

Contraction Hierarchies solve this by pre-processing the map offline:

• Remove less important nodes (local side streets, residential lanes)

• Add shortcut edges that preserve correct travel times but skip the noise

• Build a hierarchy: local streets → main roads → highways

When you search, the route algorithm focuses on the highway layer instantly, and zooms back down to street level once you’re near the destination.

This results in routing that's 10 to 100x faster than running A* on the raw road network.

The traffic problem

All that graph stuff gives you the theoretically fastest route based on road structure alone.

But roads have traffic. Traffic sucks. Traffic changes every 30 seconds.

Back in the early days, Google Maps relied on government road sensors. Physical hardware bolted to highways by municipalities. It worked. Kinda. But sensors were expensive, slow to deploy, and mostly limited to major highways.

But today, they crowdsource traffic data directly from users.

When you use Google Maps with location enabled, your phone anonymously sends back your speed and your location. Google combines that signal from every phone on every road and converts it into those green/yellow/red lines you see on the traffic layer.

Over 2 billion people use Google Maps every month.

Which means Google gets two billion moving data points.

More users = more data = more accurate traffic = better ETAs for everyone.

On top of live crowdsourced data, Google also adds n:

• Historical traffic patterns — Tuesday at 5pm always has bad traffic and Google already knows that

• Road sensor data from municipalities

• User-reported incidents — accidents, construction, road closures

• ML models predicting conditions 30 minutes ahead, not just now

That's why your ETA updates mid-drive.

The algorithm literally recalculated.

Which means every time you get directions, you're using 70 years of computer science.

Pretty cool, honestly.

Oh right, you’re a nerd. Here’s some cool resources

• A* Search Explained — the best visual explanation I've found

• Contraction Hierarchies - Great explanation that showcases the benefits

• Towards AI — Algorithms That Power Google Maps Navigation

Thanks to everyone who submitted!

SiddhantSharma313, gcavelier, Coducks2, Neverever1705, Hbear10, hamooo21112655, Ayushman-Mandhotra, KArtoffelUTE, carolina-jung, cwyner, and Manzolillom!

Seven Boom!

Create a function that takes an array of numbers and for every 7 found, add one "Boom!" to your result. If no 7 is found anywhere, return "there is no 7 in the array".

Examples

sevenBoom([1, 2, 3, 4, 5, 6, 7])
output = "Boom!"
// One 7 found → one "Boom!"

sevenBoom([8, 6, 33, 100])
output = "there is no 7 in the array"
// No 7s found anywhere.

sevenBoom([2, 55, 60, 97, 86])
output = "Boom!"
// 97 contains one 7 → one "Boom!"

sevenBoom([7, 77, 100])
output = "Boom! Boom! Boom!"
// 7 has one 7, 77 has two 7s → three total

Notes

• Check every digit of every number, not just whether the number equals 7.

How To Submit Answers

Reply with

• A link to your solution (github, twitter, personal blog, portfolio, replit, etc)

• or if you’re on the web version leave a comment!

• If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

Want to advertise in Sloth Bytes?

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.