TomTom’s Mapmaking Platform Unit – Lots of data, lots of opportunity to grow as a Java engineer
As Java engineers, data is our fast food – there’s lots of it around, and we consume lots of it as we process line after line of code. But we also know that so much more is asked of us, in terms of decision-making, speed and efficiency, etc. How does TomTom manage these factors, while building the best possible product? Our Content Production Platform Product Unit (PU CPP) is our answer.
So, what is PU CPP? It’s an engineering unit within TomTom that manages, maintains and upgrades our transactional map-making platform. This platform is the heart of TomTom’s technology, enabling continuous real-time data integration, which in turn allows other teams in TomTom to make our maps.
All these teams, within PU CPP and other units, work with a very broad purpose – we want everything we do to drive us towards our vision of a world with low emissions, complete safety on the road and zero congestion. This is a very real and constant vision, so it’s vital that our maps are as up to date as possible, in real time.
Ultimately, it all comes down to one thing – quick but precise data integration at scale. Let’s dive into the details and challenges that our Java engineers face every day.
The challenge for PU CPP and its Java engineers
Maintaining this map-making platform isn’t a simple task. On one side, we have the users that are utilizing the platform continuously to update our maps, with multiple users working on the maps at once. On the other side, we have engineering teams that are extending and building upon the platform to automate their map-making processes. This causes a constant inflow of requests for changes to the core of the platform.
The focus points of this process can be summarized with two key words – usage and throughput. Usage simply refers to how an engineer or developer uses our map-making platform to input a change (adding in a new road, as a simple example). Throughput is the time it takes for this change to be fully integrated within our final map.
Now, picture this within a wider context – it’s a global map, with TomTom’ers working on it in locations from north to south, east to west. Usage and throughput are constant, and there’s a lot of both. More importantly, it all needs to be processed quickly and precisely.
So, how do we manage all of this while continuing to innovate? Well, peering past all the zeroes and ones, it starts with the people TomTom hires, the responsibility that these engineers take on and the initiative that they show to solve problems at any given moment in exciting ways. We don’t want to glide over this though – what are the processes used within PU CPP and how do the Java engineers in the unit tackle these daily?
Ownership, getting the most out of our data and collaboration
Our ambitions are big – we want to play our part in reshaping the way we travel, for our benefit and the environment’s. So, we’re always on the lookout for experts who see the potential in location technology to make a difference. For us, it's not just about having the right mindset, but also being able to take ownership of projects and processes within a team.
Our software and databases are constantly growing, so any one part of the platform will see a serious amount of data flowing into it. As PU CPP experiences high volumes of usage and throughput, CPP engineers are divided into teams that take full ownership of different parts of the platform, leading to increased efficiency.
This is where all our expertise comes in handy. With ownership comes the need for input on how to best solve a request. We can all write code, but we always need to think beyond the four edges of the screen. What will our users expect from an update? What’s the time frame? Does the solution we’ve discussed get the most out of our data?
We all bring that knowledge into our team meetings, where everything is thrown on the table – we do not shy away from exploring alternatives. Could machine learning improve throughput, for instance? Do your research, and there’ll be ears to hear it.
Everyone has a part to play and no idea is dismissed, so long as it contributes towards our end goals. So, there’s only question left to ask.
What could a Java engineer look forward to if working in PU CPP?
While we’re all team players at TomTom, creativity and solution-focused mentalities are essential as we’re dealing with data that changes constantly. Terabytes of database traffic; millions of modifications to our map; hundreds of thousands of quality rules – all of this happens within an hour. It’s these challenges, and the scale at which they occur, that leads to our Java engineers being hot on their toes.
So, test out solutions that go beyond the expected - your voice counts, every idea is heard. Don’t think in terms of the familiar and the safe. TomTom is built around a boundary-pushing tech culture – we're evolving, introducing new and exciting technologies to help us achieve our goals.
Our work matters within PU CPP. Every day brings fresh challenges – everything will feel significant, as it all contributes towards our global ambitions. Our databases are growing – we want you to grow with it.
You’ll know the scripts, languages, software stacks. You’ll get to work as an expert with teams of experts who’ll guide any engineer to success. Plus, there are learning resources – both internal and external – that can help expand your knowledge. You’ll be a CPP sage in no time.
We’ve announced our vision of a safer, cleaner, congestion-free world – only the best maps and Java engineers like you will help us achieve that.
Java engineer? Let’s talk.
We're always on the lookout for Java engineers to join our team and solve mobility problems for millions, helping us make the world move.
People also read
Creating our maps – How Java engineers shape the future of mobility within the Maps Unit
Driving change for our maps – Why the Navigation Data Standard Unit excites Java engineers