Android Engineering at Uber: RIBs, Scale, and Two Apps

Android engineer at Uber in 2026

Uber is one of the largest native Android shops in the world, and the shape of the work follows the shape of the business. There are two flagship consumer Android apps (the Rider app and the Driver app), the Uber Eats app, plus a merchant-facing surface, and they run in dozens of countries across an Android device tail that includes very low-RAM phones on inconsistent networks. That last detail matters more than the headcount. Uber Android engineers spend real time thinking about cold-start time, app size, background battery, and offline behavior, because a noticeable fraction of trips begin on devices and networks that a typical Bay Area engineer never tests on.

The Rider and Driver apps are different products with different constraints. The Rider app is bursty and foreground-driven: open the app, request a ride, follow it on the map, pay, rate. The Driver app is long-running and background-heavy: it has to run for an entire shift, hold GPS and trip state through dropped connections, surface earnings and offers, and fail safely when the device is plugged into a windshield mount in 35 degree heat. Engineers tend to specialize: a maps and trips engineer on Rider does different work day-to-day from a driver platform engineer who lives in foreground services, battery, and reliability instrumentation.

The other defining feature of Android at Uber is the codebase organization. Uber publishes RIBs, the Router-Interactor-Builder architecture, as open source, and the production Android apps are built on it. RIBs is not a UI framework; it is a way to express the app as a tree of business-logic units (the Interactors), each with a Router that owns child RIBs and a View that the Interactor drives as a side effect. The practical result is that hundreds of Android engineers can ship into the same app without stepping on each other, because feature ownership maps cleanly to subtrees of RIBs. Onboarding to RIBs takes time; candidates from Activity-and-Fragment shops should expect a real ramp before the architecture clicks.

Interview process

Uber's Android interview loop is a recognizable big-tech shape. The recruiter screen establishes the role, level, and team area (Rider, Driver, Eats, platform, or a horizontal team like maps or payments). A technical phone screen follows, typically a coding round in Kotlin or Java solved in a shared editor, occasionally with a small Android lifecycle or threading twist depending on the interviewer.

The onsite is usually four to five rounds:

• Coding: one or two rounds of medium-to-hard algorithm and data-structure problems. Patterns are standard interview material; the bar is correctness, clarity, and complexity reasoning, with credit for catching edge cases without prompting.
• Android fundamentals: lifecycle, process death, threading, memory, configuration changes, ANRs, jank, and Jetpack components. Expect questions about how you would diagnose a frame-time regression, shrink an APK, or chase a memory leak on a real device.
• System / app design: design a feature end-to-end, for example an offline-friendly trip view, a background location pipeline that respects battery, or a payments flow with retries. Uber interviewers push hard on failure modes, partial connectivity, and the long device tail rather than generic distributed-systems trivia.
• Architecture / RIBs round: not always labeled as such, but it is common for the design or fundamentals round to drift into how you would decompose a feature into RIBs (or your equivalent). You are not expected to know RIBs going in, but you are expected to reason cleanly about separating business logic from presentation and routing.
• Behavioral: ownership, dealing with ambiguity, cross-team collaboration, production incidents, and how you handle trade-offs between velocity and reliability.

Two notes on the loop. First, Uber takes real-device fidelity seriously. Saying "I would test on a Pixel" is a weak answer; saying "I would profile cold-start on a low-RAM Android Go device with a throttled network and the Driver app's foreground service running" is a real one. Second, the levelling band matters: an L5 (Senior) candidate is expected to drive design rounds, not just answer them.

Compensation by level

Uber is a public company (NYSE: UBER) since the May 2019 IPO, so equity is denominated in real RSUs and the comp picture on Levels.fyi has good fidelity. The numbers below are pulled from Levels.fyi self-reported offers and refreshes for software engineers, with Android falling on the same ladder; they are directional and should be validated with a recruiter.

• L3 / SDE I (entry): roughly $180K-$240K total, weighted toward base and sign-on with a smaller RSU grant.
• L4 / SDE II (mid): roughly $260K-$340K total, with RSUs becoming a larger share.
• L5 / Senior SDE: roughly $340K-$480K total, with equity typically the dominant component.
• L5b / Senior II: a wider band that overlaps L5 at the low end and reaches into the $500Ks at the top.
• L6 / Staff SDE: roughly $500K-$750K+ total in recent self-reports; staff Android is thinner than overall SWE staff data.
• L7 / Senior Staff and above: thin sample sizes, but self-reports cluster well above $750K total.

Three caveats. First, Uber RSUs are real public-market shares, so total comp moves with the share price between offer and vest; numbers above reflect grant-date values. Second, Uber uses a quarterly vest cadence after a one-year cliff, which smooths out comp but makes the share-price sensitivity real. Third, Android-specific medians on Levels.fyi are thinner than overall SWE medians, so individual data points can swing the published ranges. The best signal is to ask a recruiter for the level band in writing and to compare against the cross-company levels.fyi/t/software-engineer benchmarks.

Tech stack: RIBs (Uber-OSS) + native Android + Compose adoption

Uber's Android stack is best understood in three layers: an architecture layer dominated by RIBs, a UI layer in transition from Views to Compose, and a platform layer that touches maps, payments, and a Go-heavy backend. The picture below stitches together public references from eng.uber.com, the Uber Engineering blog, and the open-source RIBs repository.

• RIBs (Router-Interactor-Builder): published at github.com/uber/RIBs, RIBs is Uber's mobile architecture for cross-platform mobile applications. The app is a tree of RIBs, each with an Interactor (business logic), a Router (which child RIBs are attached), and optionally a View with a Presenter. Business logic drives UI, not the other way around. Dependency injection is via Dagger, with a Builder per RIB scoping dependencies. The pattern was designed to let large teams ship into the same app without merge contention.
• Languages: Kotlin is the primary language for new code; Java still appears in older modules. Backend services that the Android client talks to are heavily Go and Java, with internal RPC and schema tooling. Android engineers do not write Go in normal flow, but reading service code is common when debugging end-to-end issues.
• UI: Views and Compose: large parts of the apps are still XML Views with custom view systems, and Jetpack Compose adoption is incremental rather than a rewrite. Newer surfaces and in-flight redesigns increasingly use Compose, with RIBs Views hosting Compose content. Candidates should be fluent in both.
• Concurrency and state: Kotlin coroutines and Flow are the modern path; older RIBs code uses RxJava, and significant Rx remains in production. Comfort with both is expected at L5.
• Networking and offline: an internal RPC layer over HTTP, with retry, backoff, and offline-friendly caching patterns. The Driver app in particular has heavy offline and reconnection handling, since drivers often work in low-signal environments.
• Maps and location: maps are a core surface, with Uber's own map data and rendering investments documented on eng.uber.com. Foreground services drive long-running location updates on the Driver app, with battery and OS background restrictions as first-class constraints.
• Build, CI, and modularization: Gradle with internal plugins, heavy modularization aligned to RIB ownership, and an internal CI system. Build times at this scale are a real engineering surface; Uber has published on build performance, dependency analysis, and code-gen.
• Observability: in-house crash, ANR, and performance telemetry feeds dashboards used by Android platform teams; frame-time, cold-start, and battery regressions are tracked release over release.

For an Android candidate, the practical implication is that RIBs is the dominant local mental model, but the rest of the stack is still recognizably modern Android. Engineers who land well are fluent in Kotlin, comfortable with both Views and Compose, and willing to lean into the architecture rather than fight it.