Why Uber's Loop Is Different

Uber's behavioral loop has to be understood through the lens of the cultural reset the company went through in 2017 and the years that followed. The pre-2017 framing, which is what most public coverage of Uber's culture still references, was retired and replaced. Under Dara Khosrowshahi's leadership the company introduced a new articulation of cultural norms that is now the published rubric for behavioral interviews. Candidates who walk in expecting the older framing, or who reach for the dated stereotypes from the early-2010s coverage, look like they did not do the reading. Worse, they are answering against a values rubric the company has explicitly moved away from.

Three things stand out about how Uber currently evaluates behavioral signal:

1. The eight cultural norms are the actual rubric. They are not marketing language. Interviewers are briefed to grade specific behavioral answers against specific norms, and the debrief format references which norms the candidate demonstrated and which they missed. Two norms in particular carry disproportionate weight in IC engineering loops: 'we act like owners' and 'we value ideas over hierarchy'.
2. The loop emphasises ownership at the IC level. Uber's product is a global operation that runs on a lot of small teams making consequential decisions. The behavioral loop reflects this. Strong stories show the candidate making owner-level decisions at their level, not just executing on owner-level decisions made above them.
3. The cultural reset is real and graded. Interviewers are listening for whether the candidate engages with Uber's current culture rather than the public-coverage version. Stories that demonstrate the candidate has paid attention to what the company has become, not what it was, score better than stories that recite values without engaging with their context.

The Eight Cultural Norms (What Each Actually Means)

The current published cultural norms are:

1. We build globally, we live locally.
2. We are customer obsessed.
3. We celebrate differences.
4. We do the right thing.
5. We act like owners.
6. We persevere.
7. We value ideas over hierarchy.
8. We make big bold bets.

Not all eight carry equal weight in IC engineering loops. Distilled from public-facing engineering blog posts, Khosrowshahi's letters and interviews, and patterns observable across the loop:

1. We build globally, we live locally. The signal is whether the candidate thinks about how the work behaves in markets and contexts that are not their own. For an engineer, this often shows up as stories where they considered users in geographies, languages, network conditions, or device classes outside the candidate's default. The strong shape includes a specific local context that changed an engineering decision.

2. We are customer obsessed. Standard customer-obsession framing, but with an Uber-specific edge: the customer for an engineering decision might be a rider, a driver, an Eats merchant, or an Eats courier, and the strong signal is naming which one and engaging with their specific context. Stories that talk about 'the customer' generically score lower than stories that name the rider in Mumbai during peak monsoon, the driver who was paying for data, the merchant whose POS integration was down.

3. We celebrate differences. This is the inclusion norm. Strong stories demonstrate the candidate has acted on a moment of recognising that the team or the work was missing a perspective. The shape is similar to Airbnb's belonging anchor but with a specifically Uber tilt: differences in geography, in operational context, and in how the product is used in markets the engineering team is not from.

4. We do the right thing. Post-2017 this norm is graded with specific seriousness. Strong stories show the candidate making a call where the right thing was harder than the convenient thing, often involving safety, integrity, user trust, or holding the engineering bar against pressure to ship. Stories that elide an integrity question score against the candidate.

5. We act like owners. The most heavily weighted norm in IC engineering loops. Strong stories show the candidate making decisions that the formal scope did not require them to make: stepping into a problem nobody owned, taking on a long-term cost their team would not feel for a year, refusing to ship something that would saddle the next team. The shape mirrors Amazon's Ownership but with a slightly different texture; at Uber the ownership signal often involves operational consequences (an outage, a paged team, a pre-launch pull) that make the ownership concrete.

6. We persevere. The resilience norm. Strong stories show the candidate working through a real, sustained difficulty: a project that took longer than expected and did not pivot, a setback that required regrouping rather than abandoning, a system that required years rather than months to get right. The bar is multi-month or multi-year persistence, not week-long grit.

7. We value ideas over hierarchy. The idea-over-hierarchy norm. Strong stories show the candidate having a substantive disagreement with a more senior person, making the case on the merits, and the disagreement being resolved by the argument rather than by the hierarchy. The shape requires real evidence of the disagreement and a real engagement with the senior person's position, not just a candidate-was-right-and-the-senior-person-listened story.

8. We make big bold bets. The big-bet norm. Strong stories show the candidate taking on or championing work where the upside was large, the path was unclear, and the most-likely outcome was not the best outcome. This norm is more commonly probed at staff and above; for IC engineers it shows up occasionally as a follow-up rather than as a primary probe.

How the Loop Works (Format)

A typical Uber onsite for an IC software engineer:

• 5 to 6 rounds of 45 to 60 minutes
• 2 to 3 coding rounds (medium difficulty, with a strong correctness emphasis given Uber's operational stakes)
• 1 system design round (for L4 and above, often with operational-scale framing rather than abstract design)
• 1 hiring manager round (mostly behavioral, some scope-fit content)
• 1 to 2 cross-functional or peer rounds with significant behavioral content
• 1 hiring committee debrief (offline; the committee references the cultural norms explicitly when discussing the candidate)

The Hiring Committee Debrief

Uber runs a hiring committee for each candidate. The committee references the published cultural norms explicitly in its discussion. Each interviewer's debrief names which norms the candidate demonstrated and which they missed, and the committee reads these against each other looking for consistency and weight. A strong loop has multiple interviewers citing 'we act like owners' or 'we value ideas over hierarchy' with specific story evidence. A weak loop has interviewers citing the norms with thin or no story evidence.

This structure has two practical implications for candidates. First, the norms are not optional preparation; they are the rubric. Second, stories that span multiple norms cleanly are more efficient to bank, because the same story can pick up signal from multiple interviewers in the committee discussion.

Value-to-Question Mapping

Model Answers Tailored to Uber

Worked Example 1: The Same Story, Reframed for Two Norms

The underlying story is an operational-resilience project at a previous company.

Underlying story: As a senior engineer at a logistics company, I was on the team that owned our dispatch service. I noticed our dispatch failure rate during regional weather events was hitting 4% in the affected regions, three times the steady-state rate, and was driving customer support calls that were not being attributed to weather. The pattern had been visible in our metrics for months but no team owned the gap because it sat between the dispatch team (who saw it as a network resilience problem) and the platform team (who saw it as a service-design problem). I took on the work without it being part of my formal scope. I traced the failures to a cascade where our service retried against the upstream geo-database with insufficient back-off during regional saturation. I designed a regional-aware retry strategy, prototyped it, ran it past both teams, and shipped it as a joint owner with one engineer from the platform team. Failure rate during regional weather events dropped to 0.5%, and customer support calls in those windows fell roughly proportionally.

Framing 1: We Act Like Owners

'I want to share a time I took on a problem that fell between two teams and had been sitting unowned for months. At my previous company, I was on the dispatch service team. Our dispatch failure rate during regional weather events was running at 4% in the affected regions, three times our steady-state rate, and the customer support calls in those windows were not being attributed to weather, which meant the cost was invisible to the team that would have prioritised fixing it.

The problem sat between two teams. The dispatch team saw it as a network resilience problem and assumed the platform team owned the geo-database fan-out. The platform team saw it as a service-design problem and assumed the dispatch team owned the retry logic. Both views were partially right, which meant neither team felt ownership over the gap. I had been watching the pattern for months without acting on it, and I decided this was the moment to stop watching.

I owned it without asking permission first. I traced the failures and found a cascade: during regional saturation, our service retried against the upstream geo-database with insufficient back-off, which compounded the regional load and produced exactly the failure shape the metrics showed. The fix was a regional-aware retry strategy with adaptive back-off based on regional load. I prototyped it, validated it against six months of replayed weather-event traffic, and only then went to both teams to propose the joint shipping plan. I framed it explicitly: this was code that touched both team's surfaces, the work would not happen if either of us did not commit, and I was offering to lead the implementation if either team would partner. The platform team committed an engineer for the joint review and a small back-off-tuning task on their side.

We shipped in five weeks. Failure rate during regional weather events dropped to 0.5%. Customer support calls in those windows fell roughly proportionally. The thing I take away is that the problems that fall between teams stay unowned forever unless someone takes them on, and the move that works is to do the diagnostic work first and bring a concrete proposal to the partner teams rather than asking them to figure out scope with you. I have done this three more times since, and in every case the partner teams welcomed it.'

What lands: an explicit naming of the unowned problem, the diagnostic work done before going to the partner teams, the joint-shipping framing, measurable impact, and a generalised behavioral change. This is the shape of a strong ownership story at Uber.

Framing 2: We Build Globally, We Live Locally

'I want to share a time I had to think carefully about how a system behaved in regional contexts that were not the default. At my previous company, I was on the dispatch service team. Our dispatch failure rate during regional weather events was running at 4% in the affected regions, against a 1.3% steady state. We had been treating that as background noise because the global average failure rate was acceptable.

What I noticed when I segmented the data was that the regional reality was very different from the global average. In our home region, the steady state was about 0.8% and weather events pushed it to 1.5%. In two other regions where weather was more frequent and infrastructure was more variable, the steady state was 2% and weather events pushed it to 6%. The global average was hiding two regions where the user experience during weather events was substantially worse, and we were not feeling the pain because the engineers who were on call did not live in those regions.

I traced the failures to a cascade in our retry logic that did not account for regional load. The fix was a regional-aware retry strategy with adaptive back-off. I shipped it as a joint owner with the platform team. Failure rate in the worst-affected regions during weather events dropped from 6% to 0.7%. Customer support calls in those regions fell substantially.

The thing I take away is that 'global average is acceptable' is the kind of metric framing that hides regional realities, and the regional realities are where the worst customer experiences happen. I now make a habit of segmenting any reliability metric by region, by network condition, and by device class before treating it as a single number. It has caught two more regional gaps since, both of them invisible at the global average.'

What lands: the explicit naming of the global-versus-local tension, the segmentation that revealed the regional gap, the recognition that the engineers on call were not from the affected regions, and a generalised practice (now segmenting reliability metrics by region as a default). This is the shape of a strong build-globally-live-locally story at Uber.

Worked Example 2: A Fresh Story for We Value Ideas Over Hierarchy

This norm is heavily weighted in Uber's loop and has a specific shape: a substantive disagreement with a more senior person, made on the merits, resolved by the argument rather than by the hierarchy.

'I want to share a time I disagreed with a director on a launch decision and made the case on the merits. We were six weeks from launching a major payments feature at my previous company. The director had aligned the team on a launch plan that staged the rollout from one region at a time, with each region taking two weeks before expanding. The plan was conservative, defensible, and would have shipped on time.

I disagreed with the rollout shape, not with the launch decision. My read was that the regional staging would catch the kind of problems that vary across regions (currency, regulatory, partner-bank integrations) but would miss the kind of problems that vary across user types within a region (which is how I expected our edge cases to fail, given how I had instrumented the previous payments project). I thought we should stage by user cohort within a region instead, which would catch the cohort-level edge cases earlier and with smaller blast radius.

The director was a senior person I respected and had not worked with directly. The instinct was to defer; my read was that the launch would either not catch the edge cases or would catch them painfully in the second region's full ramp. I wrote a four-page doc that laid out the comparison: what each rollout shape would catch, what each would miss, the historical edge-case mix from our previous payments launch, and the projected blast radius under each shape. The doc was specific about where I was estimating and where I had data.

I sent the doc to the director directly with a request for 30 minutes of his time. The conversation was substantive. He pushed back on two of my numbers; one push was right and I revised, one I held with more data than the doc had included. He ended the meeting saying he was not yet convinced but would think about it. Two days later he came back saying he had run the doc by another senior engineer who had thought about regional rollouts before and had ended up agreeing with the cohort-staging approach. He revised the launch plan.

We launched in five weeks rather than six. We caught two cohort-specific edge cases in the first cohort that would have been substantially more painful in a regional ramp. The thing I take away is that the right way to disagree with a more senior person is not to question their authority; it is to do the work that makes the merits legible and to give them the affordance to update without losing face. I now write the doc when I have a substantive disagreement with anyone more senior, and I send it as a thinking-out-loud invitation rather than as a challenge.'

What lands: a real disagreement on a substantive question (rollout shape rather than launch decision), the doc as the medium that made the merits legible, the conceding of one number under pushback (which is the strong-rigor signal), the director's update being driven by a peer's view rather than positional pressure, and a generalised practice. This is the shape of a strong ideas-over-hierarchy story at Uber.

Red Flags & Green Flags

Green flags (the interviewer writes a strong recommendation):

• The candidate engages with Uber's current culture (post-2017 reset, post-Khosrowshahi articulation) rather than reciting older value language or reaching for stereotypes from public coverage. Engagement with the current eight norms is a strong cultural-fit signal.
• Stories include a specific customer (named by role, geography, or context) whose experience drove the engineering decision. Generic 'the customer' framings score lower.
• Ownership stories show the candidate stepping into problems that fell between teams, with diagnostic work done before going to partner teams, and a joint-shipping plan rather than a unilateral one.
• Ideas-over-hierarchy stories are graded sharply for whether the disagreement was substantive (not stylistic), whether the merits were made legible (a doc, a meeting, real engagement with the senior view), and whether the resolution came from the argument rather than from the candidate eventually deferring.
• Global-versus-local framings include specific regional realities and an awareness that the engineers on call may not be from the affected regions. The 'I segmented by region and the global average was hiding two regions' beat is high-signal.

Red flags (the interviewer writes against):

• Candidate engagement with the pre-2017 framing of Uber's culture, reaching for the older value language or for the stereotypes from early-2010s coverage. Interviewers are explicitly trained to register this as failed homework.
• Customer-obsession stories where the customer is generic. Uber has riders, drivers, merchants, and couriers, and a strong story names one.
• 'Act like owners' stories that are really just 'I worked hard'. The norm specifically grades for decisions the candidate made that the formal scope did not require them to make, often with operational consequences. Working hard within scope is not the signal.
• 'Value ideas over hierarchy' stories that are really 'I held my opinion and was eventually proven right'. The norm grades for the substantive engagement with the senior view, the merits-based case, and the resolution by argument rather than by the candidate eventually being shown to be correct anyway.
• Persevere stories where the perseverance was a week of long hours rather than multi-month or multi-year sustained work. The norm is calibrated against real sustained difficulty.
• 'Do the right thing' stories where the integrity question is elided rather than named. Post-2017, Uber grades this norm with specific seriousness, and stories where there was an integrity question and the candidate dodged naming it score against.

Mock Interview Walkthrough: A Behavioral Round

The following is a simulated 50-minute behavioral round at Uber. Interviewer-internal-reaction commentary in italics. The candidate is interviewing for an L5 engineer role.

Interviewer: 'Thanks for joining. I will be asking some questions about how you have worked through engineering challenges. Take a minute to think before you answer if you need it. First one: tell me about a problem that fell between teams and that nobody owned, that you took on.'

Interviewer mental note: probing 'we act like owners'. I want a problem that was genuinely unowned, diagnostic work done before going to partner teams, and a joint-shipping outcome.

Candidate: [delivers the dispatch-resilience story framed for ownership, as in Worked Example 1.]

Interviewer mental note: textbook ownership shape. The diagnostic work first, the joint-shipping framing, the measurable impact, the generalised practice. Strong on 'we act like owners'.

Interviewer: 'Tell me about a time you disagreed with a more senior person on a substantive engineering decision. Walk me through what you did.'

Interviewer mental note: probing 'we value ideas over hierarchy'. I want substantive disagreement, real engagement with the senior view, merits-based case, and resolution by the argument rather than by deference.

Candidate: [delivers the rollout-shape disagreement story, as in Worked Example 2.]

Interviewer mental note: very strong. The disagreement is substantive (rollout shape), the doc is the medium, the conceding of one number under pushback is the rigor signal, and the director's update via a peer's view is the right shape for resolution. Strong on ideas-over-hierarchy.

Interviewer: 'Tell me about a time you considered a market or a regional context that was not your default and how it changed your engineering decision.'

Interviewer mental note: probing 'we build globally, we live locally'. I want a specific regional reality and an awareness that the default is not the only context.

Candidate: [delivers the same dispatch-resilience story framed for build-globally-live-locally, as in Worked Example 1, framing 2.]

Interviewer mental note: same story, different foreground. The segmentation by region is the right move. The recognition that the engineers on call were not from the affected regions is a strong empathy signal. The generalised practice (segmenting reliability metrics by region as default) is exactly the cultural posture I want. Strong on build-globally-live-locally.

Interviewer: 'Tell me about a moment you held the engineering bar when there was pressure to ship.'

Interviewer mental note: probing 'we do the right thing'. I want a real pressure moment, a real bar held, and an integrity question named cleanly.

Candidate: [delivers a fresh story about pulling a launch back by ten days because a security review found a token-leak path that the team was inclined to ship-and-patch given the deadline pressure, including the conversation with the PM and the director, the explicit naming of the integrity question (we would be shipping a known security regression), and the outcome (the patch shipped, the launch went out clean, no incident).]

Interviewer mental note: this is exactly right. The integrity question is named explicitly (a known security regression is not a defensible thing to ship). The decision was costly (ten days slipped). The outcome was the right one. Strong on 'we do the right thing'.

Interviewer: 'Last one. Tell me about a time the team was missing a perspective and what you did.'

Interviewer mental note: probing 'we celebrate differences'. I want a specific perspective, a specific person who held it, and a specific change that came out of acting on it.

Candidate: [delivers a story about an internal tooling project where the team had been designing for the engineers in the home office and the candidate noticed the engineers in two satellite offices were being treated as second-class users, including the colleague in the satellite office whose feedback drove the redesign and the specific change in how the tool worked for users on slower VPN connections, with a measurable engagement uplift after the redesign.]

Interviewer mental note: real perspective, specific colleague, specific change, measurable outcome. Strong on 'we celebrate differences'.

Debrief outcome: Strong recommend across 'we act like owners', 'we value ideas over hierarchy', 'we build globally, we live locally', 'we do the right thing', and 'we celebrate differences'. Multiple norms touched with specific story evidence; the hiring committee will weight this loop highly.

How to Prepare in 8 Hours

• Hour 1: Read Uber's current published cultural norms on the careers page, plus recent Khosrowshahi letters and engineering-blog posts. Note that the norms are post-2017; engage with the current articulation, not with older versions or with public-coverage stereotypes from the early 2010s.
• Hour 2: Identify which of your stories already cover 'we act like owners' and 'we value ideas over hierarchy'. These are the two most heavily weighted norms in IC engineering loops; if you do not have at least one strong story for each, this is the gap to close.
• Hour 3: Identify a 'we build globally, we live locally' story. If your work has been single-region or single-context, find a moment where you considered a regional, network, language, or device-class context outside your default. The story shape requires real specificity.
• Hour 4: Identify a 'we do the right thing' story where an integrity question was named explicitly. Stories that elide the integrity question score against; stories that name it cleanly are high-signal.
• Hours 5-6: Write tailored framings for each of the top five norms (12 to 15 minutes per norm). Where possible, build stories that span two norms cleanly so that the same story picks up signal from multiple interviewers.
• Hour 7: Practice the 'tell me about a substantive disagreement with a senior person' shape out loud. The merits-based case, the doc as the medium, the conceding of one number under pushback, and the resolution by argument rather than by deference are the four beats. Tighten any story where one of those beats is weak.
• Hour 8: Mock interview with a friend. Ask them to push back specifically on whether your stories are pre-2017 framed (which would be a common failure mode for candidates relying on older Uber coverage). Tighten any answer that reads as engaging with an older culture rather than the current one.

Bridge to the Next Lesson

This lesson covered Uber's current culture, defined by the eight cultural norms in the post-2017 articulation, with 'we act like owners' and 'we value ideas over hierarchy' carrying the most weight in IC engineering loops. The next lesson, OpenAI: Mission Alignment and Safety, covers a company in a very different cultural moment: an AGI lab where the mission is the most graded signal in the room and where the unique cultural challenge is working on capabilities while caring substantively about safety. The contrast is instructive. Uber grades for whether you act like the company is yours; OpenAI grades for whether you carry the mission with the seriousness it asks for.