Uber SDE onboarding and first 90 days tips 2026

I walked into the Uber Greenlight hub on a Monday morning, badge still warm from the printer, and the hiring manager slid a printed onboarding checklist across the table, pointing to the first milestone: “Ship a small feature to rider‑app by day 30.”

TL;DR

Uber’s SDE onboarding is a structured 90‑day ramp that expects new hires to deliver production code by the end of month 1, own a small service by month 2, and lead a cross‑functional experiment by month 3, with performance measured against clear OKRs and regular feedback from a buddy and manager.

Who This Is For

This guide targets software engineers who have accepted an SDE offer at Uber (L3‑L5) and want concrete actions for the first three months, especially those moving from larger tech firms or startups and needing to navigate Uber’s internal tooling, on‑call rotation, and data‑driven culture quickly.

How does Uber's SDE onboarding process work in the first 90 days?

Uber splits the first 90 days into three 30‑day phases with distinct deliverables. In phase 1 (days 0‑30) the focus is on environment setup, completing mandatory safety and privacy trainings, and shipping a trivial but visible change to the rider‑app or driver‑app codebase. In phase 2 (days 31‑60) engineers are assigned to a small team-owned service, expected to fix bugs, add a feature flag, and participate in on‑call shadowing. In phase 3 (days 61‑90) the new SDE leads a lightweight experiment, writes a design doc, presents results at a team demo, and begins owning a component of the service’s SLOs. Throughout each phase a buddy checks in weekly, and the manager holds a formal feedback session at the end of each month.

> 📖 Related: Uber PM Culture Guide 2026

What are the key expectations for an SDE during Uber's first 90 days?

The core judgment is that Uber values impact velocity over perfection; new SDEs must show they can move from code commit to production release within two weeks and iterate based on data. Specifically, engineers are expected to close at least one Jira ticket per week that touches user‑facing code, write unit tests that achieve ≥80 % coverage for changed files, and post a clear rollout plan in the internal release tracker before any deploy. Managers also look for proactive communication: posting daily stand‑up updates in the team Slack channel, asking clarifying questions in design reviews, and volunteering for on‑call shadow after the first month. Failure to meet these velocity signals often results in a performance improvement plan, even if the code quality is high.

How should I set up my development environment and access Uber's internal tools?

The first step is to complete the laptop provisioning workflow through Uber’s internal IT portal, which installs the standardized Linux image, the Uber‑specific CLI (ubercmd), and access to the monorepo via Bazel. New hires must then enroll in the two‑factor authentication system, request access to the rider‑app and driver‑app repositories, and complete the “Code Review 101” self‑paced module before their first PR. A common pitfall is skipping the internal DNS configuration step, which leads to failed service discovery; the fix is to run ubercmd network setup and verify with dig internal.uber.com. Once the environment is green, engineers should clone the uber/mobile repo, run the local emulator suite, and submit a trivial documentation change to verify the end‑to‑end CI/CD pipeline.

What are the common challenges new SDEs face at Uber and how to overcome them?

One frequent challenge is navigating the sheer scale of Uber’s microservices ecosystem, which can cause analysis paralysis when trying to understand dependencies. The judgment is that new hires should treat the system as a set of well‑defined APIs rather than attempting to memorize every service; they rely on the internal service catalog (Swagger UI) and generate mock clients for integration tests. Another challenge is the on‑call rotation, which begins after day 45 and can feel overwhelming due to high alert volume. The effective approach is to shadow a senior engineer for two full shifts, document the runbook steps for each alert type, and gradually take ownership of low‑severity tickets before handling severe incidents. A third issue is the performance review bias toward visible impact; engineers who focus solely on refactoring without shipping user‑visible changes often receive lower ratings, so they should pair any refactor with a feature flag that enables a measurable improvement for riders or drivers.

How does Uber evaluate performance and provide feedback during onboarding?

Uber uses a lightweight OKR framework tied to the three‑month milestones, with progress reviewed in monthly one‑on‑ones and a formal calibration at day 90. At the end of each month the manager scores the engineer on four dimensions: delivery velocity (tickets completed per week), code quality (review comments and test coverage), collaboration (buddy feedback and cross‑team participation), and ownership (on‑call participation and incident resolution). Scores are calibrated against the level’s expectations; for example, an L4 SDE must achieve an average score of 3.5/5 to be considered on track. Feedback is delivered via a shared doc that lists concrete examples of good and bad behavior, and engineers are encouraged to create a personal action plan before the next review cycle.

Preparation Checklist

Complete Uber’s laptop provisioning and verify access to the monorepo and internal tools within the first 48 hours.
Finish all mandatory safety, privacy, and security trainings before day 5 to avoid delays in badge activation.
Ship a non‑trivial but low‑risk change to rider‑app or driver‑app by day 30 and document the rollout steps in the release tracker.
Shadow a senior engineer on‑call for two shifts, annotate the runbook, and begin handling low‑severity alerts by day 45.
Work through a structured preparation system (the PM Interview Playbook covers system design fundamentals with real debrief examples) to refresh behavioral storytelling for design reviews.
Draft a one‑page experiment proposal by day 60, gather feedback from the product partner, and execute the A/B test by day 75.
Schedule a mid‑month check‑in with your buddy and manager to adjust OKRs based on early velocity data.

Mistakes to Avoid

BAD: Spending the first two weeks only reading internal wikis and waiting for a “perfect” task before writing any code.

GOOD: Submitting a trivial typo fix in the rider‑app on day 3, then iterating on a small feature flag by day 15 to demonstrate end‑to‑end flow.

BAD: Ignoring on‑call shadowing and waiting until the first solo shift to learn the alerting system.

GOOD: Pairing with a buddy for two full on‑call shifts, logging each incident, and practicing the mitigation steps in a sandbox environment before taking solo responsibility.

BAD: Focusing exclusively on code refactoring without tying changes to user‑visible metrics or feature flags.

GOOD: Pairing every refactor with a feature flag that measures latency or error rate improvement, then presenting the data in the team demo.

FAQ

What salary range should I expect for an SDE role at Uber?

Based on Levels.fyi Uber compensation data, base salaries for SDE positions typically fall between $131,000 and $252,000, with the midpoint around $161,000 for L4 roles; total compensation includes equity and performance bonuses that vary by level and location.

How many interview rounds does Uber’s SDE process usually involve?

Glassdoor Uber interview reviews indicate the process consists of four to five rounds: a recruiter screen, two technical coding interviews, a system design interview, and a behavioral or leadership principles interview, each lasting about 45 minutes.

What is the most important skill to demonstrate in the first 90 days at Uber?

The most important skill is the ability to ship production code quickly and learn from data; managers prioritize velocity and impact over perfect code, so delivering a user‑visible change within the first month and iterating based on metrics is critical for a positive onboarding review.

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.