At Uber, our mission is to bring transportation as reliable as running water to everyone, everywhere. Our open, public API is a key part of our strategy to make Uber easier to use wherever you might need it in every app, device, and computing environment in today’s busy world.

The Developer Platform mission is to empower developers to build moving experiences. To this end, we design and develop the API, SDKs, and developer tools for integrating Uber’s transportation and logistics network into the world’s best apps and services.

Since its inception in August 2014, the platform has come a long way, sparking some of Uber’s most exciting product partnerships including Facebook Messenger and Amazon’s Echo. And with our new Trip Experiences API, we’re working to make your favorite apps better by creating optimized experiences based on your trip context.

Examples of how the Uber Trip Experience can be integrated with experiences in outside apps.

The Uber Developer Platform team sits at the intersection of many engineering teams. We work closely with other parts of the company, including business development, international growth, product development, and marketing.

Our developer relations team works in the Uber Engineering org right alongside the developers who build out our API. My team—the API Features team—works closely with the platform engineers that support and scale what we build, resulting in much faster feedback cycles. In turn, the partner engineers support and promote our work to external platform partners and the broader developer ecosystem.

To help illustrate the work we do, I’d like to tell you a bit about the work I do, and introduce you to two of my teammates: Goutham, a platform engineer, and Andrew, a partner engineer.

Features Engineer

Christine Kim

I am a full-stack engineer on the Features team. We focus on building new APIs, endpoints, and features for our developers.

Uber promotes autonomy, which means that I own every aspect of a feature, from initial design to socializing the technical proposal to implementation to seeing my feature through to launch. I drive many product decisions that go into my feature in addition to design decisions.

We work in small, fast, iterative cycles. We ship code everyday and each new feature is constantly being tested. Today, I’m working on new endpoints that will complete a new feature we recently launched called Trip Experiences. The GET /requests/current endpoint we built for Trip Experiences allows developers to get context and details about any ongoing ride that a user is on. I’m working on adding functionality to this endpoint, like being able to update the current trip’s destination or cancel it with PATCH and DELETE methods.

After implementing these endpoints, I’ll work with a platform engineer to tweak the testing and monitoring, who will develop a new integration test around the endpoints that I’ve built. Then I’ll sync with a developer relations partner engineer to plan its launch with our partner.

I’m constantly working in quick cycles like this. It’s incredibly rewarding to go from rapid iteration of feature ideas to full realization in a matter of weeks.

Platform Engineer

Goutham Nath

I’m the engineering lead on the Developer Platform team, responsible for the internal platform component of our API. I focus on the performance, monitoring, scalability, and uptime of our service. For example, I’m building an instant alerting system and creating a robust monitoring and testing infrastructure for our developer platform.

This week, I’m working on our new testing infrastructure. We are building a service for continuous integration testing for every API endpoint and feature that we support in every city. This will allow us to test critical features in every Uber operational city and catch granular bugs immediately.

I live in the East Bay with my family and use BART to get to Uber’s San Francisco office. I usually head to work at around 10 am after having breakfast with my family, and by then the office is already buzzing with energy.

I spend most of my day coding at my desk, but when I’m not coding, you can find me communicating with engineering teams or coordinating projects with fellow teammates. Later today, I’ll be working with Christine to create a new continuous integration test for a new endpoint she has built.

Uber moves at a fast pace, and there’s a healthy pressure that makes my work both challenging and rewarding. There’s certainly pressure to meet our ambitious goals, but I work efficiently and manage my time so I can have a fulfilling work-life balance. I treat myself to a vacation or weekend trip with family every now and then, and I make it home across the bay to have dinner with my family every night.

Partner Engineer

Andrew Noonan

My role—Developer Relations Partner Engineer—is to empower developers. I’m on the front lines with partners like Amazon, Baidu, and Facebook, working with them to build amazing products on top of the Uber Developer Platform. I get to see firsthand what sorts of innovations they’re building with our API.

I’m based in San Francisco with the rest of the team most of the time, but I travel around the world, from Australia to India, meeting with our strategic partners or working with developers at hackathons.

I manage business relationships, contribute to engineering work, and teach or speak at events in front of our developers. Because I interact so closely with our API partners, I get to be the voice of the customer and incorporate their feedback and requests into our roadmap. For example, the new endpoints that Christine has been building was originally a partner’s request. We worked together to refine the feature requirements, and I’ll see the results in Christine’s implementation in a few weeks. I have the rare opportunity to deliver the real-world buzz directly into the hands of the engineers working on the API.

At Uber, we don’t separate Developer Relations from the engineers building our APIs. We are unified as one team that designs, scopes, builds, launches, and supports the features together.