{"id":989,"date":"2026-06-29T10:14:17","date_gmt":"2026-06-29T10:14:17","guid":{"rendered":"https:\/\/lastroundai.com\/blog\/?post_type=iq&#038;p=989"},"modified":"2026-07-19T10:54:09","modified_gmt":"2026-07-19T05:24:09","slug":"uber","status":"publish","type":"iq","link":"https:\/\/lastroundai.com\/interview-questions\/uber","title":{"rendered":"Uber Interview Questions (2026): What They Actually Ask"},"content":{"rendered":"<p>A backend engineer who went through Uber&#8217;s loop in late 2024 described the experience this way: &#8220;Every problem had a hidden layer. They&#8217;d give you a standard graph traversal problem but frame it as &#8216;there are a million drivers and you need to find the 10 nearest ones in under 50 milliseconds.&#8217; You couldn&#8217;t just think in the abstract.&#8221; That framing tells you most of what you need to know about Uber interviews.<\/p>\n<p>Uber&#8217;s process is one of the more product-grounded loops in big tech. The coding problems skew toward real-world scenarios rather than pure puzzles, the system design questions pull directly from Uber&#8217;s infrastructure (ride-matching, geospatial indexing, surge pricing, real-time dispatch), and the behavioral round is calibrated against a specific set of cultural values the company refreshed under Dara Khosrowshahi. This page covers the 2026 loop based on verified candidate reports from Glassdoor, interviewing.io, Blind, LeetCode Discuss, and several first-person Medium accounts from 2024 to early 2026.<\/p>\n<div class=\"iq-stats not-prose\"><div class=\"iq-stat\"><span class=\"iq-stat__value\">4-6 weeks<\/span><span class=\"iq-stat__label\">Process<\/span><\/div><div class=\"iq-stat\"><span class=\"iq-stat__value\">4-6<\/span><span class=\"iq-stat__label\">Rounds<\/span><\/div><div class=\"iq-stat\"><span class=\"iq-stat__value\">LC Medium-Hard<\/span><span class=\"iq-stat__label\">Coding<\/span><\/div><div class=\"iq-stat\"><span class=\"iq-stat__value\">Virtual onsite<\/span><span class=\"iq-stat__label\">Format<\/span><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--easy\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"easy\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Easy questions<\/h2><span class=\"iq-dsec__n\">14<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Merge overlapping intervals<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Arrays<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Sort by start time. Iterate through: if the current interval starts at or before the end of the last merged interval, extend the end to the max of both ends. Otherwise, start a new merged interval. Edge cases to discuss: single interval, totally contained intervals, and intervals that share exactly one endpoint (most interviewers at Uber want [1,3] and [3,5] merged to [1,5]).<\/p>\n<p>Shows up in coding screens and OAs. Uber sometimes frames it as &#8220;merge overlapping surge zones in a city map&#8221; which is the same problem with geographic labels on the intervals.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Tell me about a time you significantly improved the experience of a customer or driver.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The &#8220;trip obsessed&#8221; value. The customer doesn&#8217;t have to be an Uber rider; it can be an internal customer, a downstream team, or an external API consumer. What matters is that you can tie the technical work to a measurable improvement in someone&#8217;s experience.<\/p>\n<p>Weak answers describe infrastructure improvements without connecting them to user impact. Strong answers name the specific failure mode users experienced (&#8220;drivers were seeing stale pickup ETAs because the cache TTL was too long, causing 15% of pickups to be 3+ minutes late&#8221;), describe the fix, and quantify the improvement. A 15% reduction in late pickups is a story. &#8220;I improved caching performance&#8221; is not.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Describe a time you received difficult feedback. How did you respond?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The interviewer is checking for defensiveness. A story where you immediately agreed the feedback was correct and changed everything about how you work reads as either fabricated or as someone with no independent judgment. A story where you understood the feedback, asked a clarifying question or two, and made a specific change, even a partial one, reads as credible.<\/p>\n<p>Performance review feedback works here, but a sharper answer often comes from feedback given informally, in a code review, in a retro, in a one-on-one, since it shows the feedback loop you operate in day to day rather than a formal process you only encounter once a year.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Tell me about a time you took on something significantly outside your current scope or skillset.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The &#8220;bold bets&#8221; value. Uber historically rewards engineers who stretch beyond their defined role, particularly those who identify a gap in the system that no one owns and just fix it without waiting for permission. A story about picking up an unfamiliar codebase, shipping a fix under time pressure, and landing it cleanly works well here.<\/p>\n<p>The follow-up often goes toward: &#8220;What did you learn that you didn&#8217;t expect to?&#8221; Have a real technical answer. Learning that you should always read the runbook before making changes to a production config is more credible than &#8220;I learned the value of teamwork.&#8221;<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Why Uber? What&#039;s specifically interesting to you about what we&#039;re building right now?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Uber is in a genuinely interesting technical moment: autonomous vehicle integration (Uber Advanced Technologies Group spun out but Uber still has AV partnerships), the expansion of Uber Eats into non-food verticals, the push into pre-scheduled rides and corporate travel, and the ongoing engineering work on their global dispatch and payment infrastructure. Any of these are valid hooks.<\/p>\n<p>What doesn&#8217;t work: generic &#8220;I love transportation technology&#8221; answers, anything that confuses Uber&#8217;s current technical direction with Waymo or Lyft, or answers that name products Uber has deprecated. Research the team you&#8217;re interviewing with specifically. If you&#8217;re interviewing for the marketplace engineering team, know what their tech stack looks like and what problems they&#8217;ve published about on Uber&#8217;s engineering blog.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s the most technically complex project you&#039;ve worked on, and what made it hard?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>This one doubles as a soft technical round. Interviewers use your answer to probe depth: say &#8220;I built a distributed caching layer&#8221; and expect direct follow-up questions about cache invalidation, consistency, and failure handling, not just narrative details about the project timeline.<\/p>\n<p>Pick the project where you can go three levels deep on any part of it if asked, not the project with the most impressive-sounding title.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How long does the Uber interview process take from application to offer?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Most candidates complete the process in four to six weeks from application to verbal offer. The online assessment is usually sent within one to two weeks of the recruiter screen. After the virtual onsite, the hiring committee review takes three to five business days. If you have a referral, the OA link sometimes comes faster and the debrief may move quicker. The longest waits tend to happen between the onsite and the decision call when the committee needs additional discussion.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Does Uber use CodeSignal for its coding interviews?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Yes, as of 2024 to 2026, Uber uses CodeSignal for both the online assessment and the live technical phone screen. Some teams or regions have used HackerRank for the OA in the past, but CodeSignal is the primary platform. During the live screen, you code in CodeSignal while on a Zoom call with the interviewer. The environment supports most common languages including Python, Java, Go, and C++.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How important is system design for Uber interviews at different levels?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>System design is a full dedicated round for L4 and above. For L3 new grads, it&#8217;s either absent or appears as a lighter architecture discussion appended to a coding round. At L5 and above, expect two system design-flavored rounds: one high-level distributed systems design and one low-level design or machine coding exercise where you implement a service or module in working code. Senior and staff candidates sometimes get an additional domain-specific round focused on Uber&#8217;s marketplace or geospatial infrastructure.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What languages does Uber accept in coding interviews?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Python, Java, and Go are the most commonly used by candidates and are well-supported by Uber interviewers. C++ is accepted but less common outside systems-adjacent roles. JavaScript is generally accepted for the OA but some interviewers prefer you use a backend language for the live screen. If you&#8217;re interviewing for a role where the team uses Go heavily (which is true for a lot of Uber&#8217;s backend services), using Go in your live screen signals genuine familiarity with the team&#8217;s actual stack.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How does Uber&#039;s behavioral round differ from Amazon&#039;s leadership principles round?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Amazon&#8217;s leadership principles round is systematic: interviewers go through a defined rubric and expect STAR format answers mapped to named principles like &#8220;Customer Obsession&#8221; or &#8220;Invent and Simplify.&#8221; Uber&#8217;s behavioral round is less formulaic in structure but just as rigorous in substance. Uber interviewers push harder on specific data and numbers, expect you to describe real trade-offs rather than just positive outcomes, and will often turn a behavioral answer into a 15-minute technical discussion if your story has technical depth. The STAR format is still useful at Uber, but the result component needs real quantitative data, not a vague qualitative improvement.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Does Uber ask hard LeetCode problems or mostly mediums?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">FAQ<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The OA sits at medium to medium-hard. The live coding rounds also land mostly in medium territory, with occasional hard-difficulty problems at senior levels. What makes Uber&#8217;s coding rounds feel harder than the difficulty label is the real-world framing (you&#8217;re solving a driver-routing problem, not &#8220;find the shortest path in a graph&#8221;) and the optimization pressure in follow-ups. A clean medium solution that you can defend and optimize on demand is more valuable here than a memorized hard solution you can&#8217;t adapt.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What is the difference between a stack and a queue, and where would each show up in a ride-hailing backend?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">data structures<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A stack is last-in-first-out. You push and pop from the same end, so the most recently added item is the first one out. A queue is first-in-first-out. You add at the back and remove from the front, so items come out in the order they arrived. Both give O(1) insert and O(1) remove when implemented with an array-backed ring buffer or a doubly linked list, the difference is purely which end you&#8217;re allowed to touch.<\/p>\n<p>In a system like Uber&#8217;s dispatch pipeline, queues show up constantly. When a rider requests a trip, that request typically lands on a message queue (something like Kafka or SQS) before a matching service picks it up, which preserves ordering and lets you buffer bursts of demand without dropping requests. A stack is less common in the request path but shows up in things like undo history for a support agent tool, or in the call stack itself when a service does recursive route computation.<\/p>\n<p>The gotcha interviewers look for is whether you understand that &#8220;queue&#8221; in casual conversation usually means a message queue with at-least-once delivery and possible reordering across partitions, which is a very different animal from the strict FIFO queue data structure you&#8217;d implement in an algorithms round. Being able to draw that line shows you can move between the CS-fundamentals framing and the distributed-systems framing without conflating them.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How does a hash map get average O(1) lookups, and what happens when two keys collide?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">data structures<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A hash map runs each key through a hash function that produces an integer, then uses that integer modulo the table size to pick a bucket. If the hash function spreads keys uniformly and the table isn&#8217;t too full, most buckets hold zero or one entry, so a lookup is just &#8220;hash the key, jump to the bucket, compare.&#8221; That&#8217;s where the average O(1) comes from. It&#8217;s an average, not a guarantee, because a badly distributed hash or a small table can degrade to O(n) if every key lands in the same bucket.<\/p>\n<p>Collisions are handled one of two main ways. Separate chaining keeps a small linked list (or a tree, as Java&#8217;s HashMap does once a bucket gets past eight entries) at each bucket, so colliding keys just get appended and a lookup walks the short chain. Open addressing instead finds another slot in the same array, using linear probing, quadratic probing, or double hashing, which keeps everything in one contiguous block of memory and tends to be more cache-friendly but degrades faster as the table fills up.<\/p>\n<p>Worth mentioning if it comes up in a design context: real hash tables resize and rehash once the load factor crosses a threshold, usually around 0.7, which is an amortized O(n) operation that happens rarely enough not to affect the average-case analysis. For something like a geospatial lookup of nearby drivers, you&#8217;d typically layer a spatial structure like a geohash or H3 index on top of hashing rather than relying on raw key equality, since you need range queries, not just exact-match lookups.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--medium\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"medium\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Medium questions<\/h2><span class=\"iq-dsec__n\">21<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Find the length of the longest subarray where the absolute difference between any two elements is at most K<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Sliding Window<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Maintain two deques tracking the current window&#8217;s maximum and minimum values. The window is valid as long as max minus min is at most K. When the window becomes invalid, shrink from the left until it&#8217;s valid again. Each element enters and exits each deque once, giving O(n) overall.<\/p>\n<p>This specific problem was reported in a December 2024 L4 backend onsite at Uber. The initial brute-force attempt ran O(n^4). The interviewer prompted optimization in two stages, first to O(n^2), then to the deque-based O(n) approach. The interviewer specifically asked: &#8220;What&#8217;s the invariant you&#8217;re maintaining in your deque?&#8221;<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\nfrom collections import deque\ndef longest_subarray(nums, k):\n\n    max_dq, min_dq = deque(), deque()\n\n    left = 0\n\n    result = 0\n    for right in range(len(nums)):\n\n        # maintain decreasing deque for max\n\n        while max_dq and nums[max_dq[-1]] &lt;= nums[right]:\n\n            max_dq.pop()\n\n        max_dq.append(right)\n        # maintain increasing deque for min\n\n        while min_dq and nums[min_dq[-1]] &gt;= nums[right]:\n\n            min_dq.pop()\n\n        min_dq.append(right)\n        # shrink window if invalid\n\n        while nums[max_dq[0]] \u2013 nums[min_dq[0]] &gt; k:\n\n            left += 1\n\n            if max_dq[0] &lt; left:\n\n                max_dq.popleft()\n\n            if min_dq[0] &lt; left:\n\n                min_dq.popleft()\n        result = max(result, right \u2013 left + 1)\n    return result\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Find the K nearest drivers to a rider&#039;s location<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Heap \/ Geospatial<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Compute Euclidean distances from each driver to the rider and maintain a max-heap of size K. For each driver, if the heap has fewer than K entries, push it. If the current distance is less than the max in the heap, pop the max and push the current driver. Return the heap contents when done.<\/p>\n<p>Reported from multiple phone screens and onsite coding rounds. The real test comes in the follow-up: &#8220;How would you handle 500,000 active drivers?&#8221; The expected answer introduces geohashing to pre-partition drivers into geographic buckets, so you&#8217;re only running the heap comparison within the relevant bucket and its immediate neighbors, not against the full driver set. Candidates who go straight to heap without addressing scale get pushed on it.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\nimport heapq\n\nimport math\ndef k_nearest_drivers(drivers, rider, k):\n\n    # drivers: list of (id, x, y), rider: (x, y)\n\n    max_heap = []  # (-distance, id)\n    for driver_id, dx, dy in drivers:\n\n        dist = math.sqrt((dx \u2013 rider[0])**2 + (dy \u2013 rider[1])**2)\n\n        heapq.heappush(max_heap, (-dist, driver_id))\n\n        if len(max_heap) &gt; k:\n\n            heapq.heappop(max_heap)\n    return [driver_id for _, driver_id in max_heap]\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Implement an LRU cache<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Data Structures<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>HashMap for O(1) key lookups combined with a doubly linked list to track recency. The head holds the most recently used entry; the tail holds the least recently used. On a get, move the accessed node to the head. On a put that exceeds capacity, evict the tail node and delete its key from the map.<\/p>\n<p>A classic that shows up in Uber phone screens and OAs. Uber&#8217;s follow-up here is usually: &#8220;How would you scale this to a distributed cache shared across multiple ride-matching servers?&#8221; That leads into a discussion of consistent hashing, cache invalidation on price updates, and whether you can tolerate stale driver availability data for a few hundred milliseconds.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">java<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-java\">\n\nimport java.util.LinkedHashMap;\n\nimport java.util.Map;\nclass LRUCache extends LinkedHashMap&lt;Integer, Integer&gt; {\n\n    private final int capacity;\n    public LRUCache(int capacity) {\n\n        super(capacity, 0.75f, true);\n\n        this.capacity = capacity;\n\n    }\n    public int get(int key) {\n\n        return super.getOrDefault(key, -1);\n\n    }\n    public void put(int key, int value) {\n\n        super.put(key, value);\n\n    }\n    @Override\n\n    protected boolean removeEldestEntry(Map.Entry&lt;Integer, Integer&gt; eldest) {\n\n        return size() &gt; capacity;\n\n    }\n\n}\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Find the minimum absolute difference in all K-sized windows of an array<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Sliding Window \/ Heap<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Use a sorted multiset (or a balanced BST equivalent) to maintain the current window of K elements. For each new element added and each element removed as the window slides, update the sorted structure in O(log K) time. The minimum absolute difference in the current window is found by checking adjacent elements in the sorted order. Overall time complexity is O(n log K).<\/p>\n<p>Reported in an Uber phone screen. The brute force is O(n * K log K), which is too slow for large inputs. The key insight interviewers want to see is that you need a data structure that supports ordered insertion and deletion, not just a simple min or max query.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Reconstruct an array from given subsequences (topological sort)<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Graphs<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Build a directed graph where an edge from A to B means A appears before B in at least one of the given subsequences. Run topological sort (Kahn&#8217;s algorithm using BFS). If the sorted output matches the original array and the topological order is unique (exactly one node with in-degree zero at each step), return true.<\/p>\n<p>Reported from a 2024 Uber onsite. The uniqueness check is the gotcha: standard topological sort implementations don&#8217;t verify uniqueness, you have to check at each BFS step that exactly one node has zero in-degree to confirm the sequence is determined.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\nfrom collections import defaultdict, deque\ndef can_reconstruct(original, seqs):\n\n    graph = defaultdict(set)\n\n    in_degree = {x: 0 for x in original}\n    for seq in seqs:\n\n        for i in range(len(seq) \u2013 1):\n\n            u, v = seq[i], seq[i+1]\n\n            if v not in graph[u]:\n\n                graph[u].add(v)\n\n                in_degree[v] = in_degree.get(v, 0) + 1\n    queue = deque([n for n in in_degree if in_degree[n] == 0])\n\n    idx = 0\n    while queue:\n\n        if len(queue) &gt; 1:\n\n            return False  # not unique\n\n        node = queue.popleft()\n\n        if idx &gt;= len(original) or node != original[idx]:\n\n            return False\n\n        idx += 1\n\n        for neighbor in graph[node]:\n\n            in_degree[neighbor] -= 1\n\n            if in_degree[neighbor] == 0:\n\n                queue.append(neighbor)\n    return idx == len(original)\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Find the largest square sub-grid where all border cells are 1s<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Dynamic Programming<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Precompute prefix sums for horizontal and vertical runs of consecutive 1s. For each cell (i, j), you know the maximum rightward and downward streak of 1s starting from that cell. Then iterate over all possible square sizes k from large to small: check if the top row, bottom row, left column, and right column all have at least k consecutive 1s using the precomputed streaks. First match is the answer.<\/p>\n<p>Reported in the initial screening round for an L4 backend role in December 2024. The interviewer accepted an O(n^3) solution but asked for the optimization. The key observation is that you don&#8217;t need to check all four sides independently once you have the streak arrays; the four corner-based lookups determine validity in O(1) per cell per size.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Count the number of islands (connected regions of land) in a 2D grid<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Graphs \/ Grid<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>DFS or BFS from every unvisited land cell, marking every connected land cell you reach as visited so it doesn&#8217;t get counted again. Each DFS or BFS call accounts for exactly one island. Time complexity is O(rows x cols) since every cell is visited once.<\/p>\n<p>A warmup-tier problem at most companies, but Uber&#8217;s version usually adds a twist: &#8220;now do it for a grid that updates in real time as new zones come online.&#8221; That&#8217;s Number of Islands II, which needs union-find instead of a fresh DFS pass every time land is added. The union-find follow-up is the actual bar here; the base DFS version is just the entry point.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Word Ladder: minimum number of transformations from source to target word<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">BFS \/ Graphs<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>BFS where each node is a word and edges connect words that differ by exactly one character. Build adjacency as you go: for each word in the queue, generate all one-character mutations and check if they exist in the dictionary. Track visited words to avoid cycles. The BFS level count when you reach the target is the answer.<\/p>\n<p>Reported from Uber phone screens multiple times across 2024 to 2025 community threads. The optimization that comes up in follow-ups is bidirectional BFS, starting from both the source and target simultaneously and meeting in the middle, which can dramatically reduce the branching factor in large word dictionaries.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Longest increasing path in a matrix<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">DFS \/ Memoization<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>DFS with memoization. From each cell, try moving in all four directions to a cell with a strictly greater value. Cache the result for each cell so you don&#8217;t recompute. The answer is the maximum cached value across all starting cells.<\/p>\n<p>LeetCode 329. Reported from an Uber OA and confirmed in an interviewing.io session for a senior role. The trickier follow-up: how does this change if you allow diagonal moves? The algorithm structure is the same; you add four more direction pairs.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Minimum cost to connect all cities (Minimum Spanning Tree)<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Graphs \/ MST<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Kruskal&#8217;s algorithm: sort all edges by weight, then use a union-find structure to greedily add edges that connect two different components. Stop when you have N-1 edges for N cities. Prim&#8217;s algorithm is an alternative starting from a single node and repeatedly adding the cheapest edge that extends the current tree.<\/p>\n<p>Reported from an Uber phone screen framed as &#8220;connecting delivery zones.&#8221; The follow-up asked which algorithm you&#8217;d prefer when edges are already given as a sparse list (Kruskal) versus when you have a dense adjacency matrix (Prim). The difference in time complexity matters: Kruskal is O(E log E), Prim with a binary heap is O((V + E) log V).<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Network Delay Time: find the minimum time for a signal to reach every node in a weighted, directed network<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Graphs \/ Dijkstra<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Classic single-source shortest path. Run Dijkstra&#8217;s algorithm from the source node using a min-heap keyed by distance. Pop the closest unvisited node, relax its outgoing edges, and repeat. Once the heap is empty, the answer is the maximum distance across all reachable nodes, or -1 if any node was never reached.<\/p>\n<p>Uber frames this as computing how long it takes an ETA update or a fare change to propagate through a mesh of regional pricing services, same weighted graph, same Dijkstra. The follow-up worth practicing: what if edge weights can go negative (network latency can&#8217;t, but pricing adjustments sometimes do)? That rules out Dijkstra and pushes the conversation toward Bellman-Ford, which is exactly the transition into the next question.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\nimport heapq\n\nfrom collections import defaultdict\ndef network_delay_time(times, n, k):\n\n    graph = defaultdict(list)\n\n    for u, v, w in times:\n\n        graph[u].append((v, w))\n    dist = {}\n\n    heap = [(0, k)]\n    while heap:\n\n        d, node = heapq.heappop(heap)\n\n        if node in dist:\n\n            continue\n\n        dist[node] = d\n\n        for neighbor, weight in graph[node]:\n\n            if neighbor not in dist:\n\n                heapq.heappush(heap, (d + weight, neighbor))\n    return max(dist.values()) if len(dist) == n else -1\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Find the cheapest route between two points with at most K stops allowed<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Graphs \/ Bellman-Ford<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Standard Dijkstra doesn&#8217;t respect a hard cap on the number of edges used, so the accepted approach is a bounded Bellman-Ford: relax all edges K+1 times, tracking the best cost to reach each node within that many hops. Using a copy of the previous iteration&#8217;s distance array when relaxing, rather than updating in place, is what stops a single iteration from chaining together more hops than allowed.<\/p>\n<p>Uber&#8217;s framing is usually a route with a fare cap tied to a maximum number of toll segments, or a maximum number of driver handoffs on a multi-leg delivery. (Side note: candidates who reach for a BFS-with-priority-queue hybrid instead of bounded Bellman-Ford almost always get the stop-count constraint wrong on the first pass, so budget extra time to trace through an example with K=1.)<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\ndef find_cheapest_price(n, flights, src, dst, k):\n\n    prices = [float(\u2018inf\u2019)] * n\n\n    prices[src] = 0\n    for _ in range(k + 1):\n\n        temp = prices[:]\n\n        for u, v, cost in flights:\n\n            if prices[u] != float(\u2018inf\u2019) and prices[u] + cost &lt; temp[v]:\n\n                temp[v] = prices[u] + cost\n\n        prices = temp\n    return prices[dst] if prices[dst] != float(\u2018inf\u2019) else -1\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Detect a cycle in a directed graph<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Graphs<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>DFS with a recursion stack (a separate set of nodes on the current active call path) alongside a visited set. If DFS reaches a node already in the recursion stack, a cycle exists. After fully exploring from a node, remove it from the recursion stack. An undirected version only needs a visited set and parent tracking, not the separate stack.<\/p>\n<p>Appears in Uber OAs and is often extended to &#8220;given a course schedule with prerequisites, can all courses be completed?&#8221; That&#8217;s LeetCode 207, same algorithm with different framing.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Tell me about a time you owned a technical problem end to end, from identification to production.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>This is the &#8220;owner mentality&#8221; question in its most direct form. Interviewers want to see that you noticed the problem (not that someone handed it to you), that you drove the investigation, that you made the fix or the architectural decision, and that you saw it through to verification in production. A story that ends at &#8220;I submitted the PR&#8221; doesn&#8217;t finish the loop.<\/p>\n<p>Strong answers include what monitoring or alerting surface you used to detect the problem, what your investigation process was, and what you put in place to prevent recurrence. An on-call story with concrete incident data works well here. Vague stories about &#8220;improving the deployment pipeline&#8221; without specific before\/after data don&#8217;t land at Uber.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Tell me about a time you failed at something important. What did you do afterward?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Uber interviewers are explicitly checking for two things here: whether you can name a real failure without deflecting blame, and whether the &#8220;afterward&#8221; part shows a concrete behavior change, not just a lesson learned in the abstract. &#8220;I take more time to test now&#8221; is weaker than describing the specific new step you added to your own process, a checklist item, a new test, a review habit, and evidence you&#8217;ve actually used it since.<\/p>\n<p>Pick a failure with real consequences, a missed deadline that cost a launch window, a bug that reached production, a design decision you had to walk back, not a manufactured near-miss that never actually went wrong.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Describe a time you pushed back on a product or business decision you thought was technically wrong.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The &#8220;boldly honest&#8221; value. Interviewers want to see that you were specific in your disagreement (not just &#8220;I had concerns&#8221;), that you brought data or an alternative, and that you could adapt when the decision went against you without becoming obstructionist.<\/p>\n<p>The follow-up is almost always: &#8220;Looking back, was the decision the right one?&#8221; Uber interviewers value intellectual honesty here. If the decision turned out to be wrong and you know it, say so and describe what you learned. If it turned out to be right despite your concerns, that&#8217;s also interesting and shows intellectual humility.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Describe a time you disagreed with your manager&#039;s direction on a project.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>This is distinct from the product-pushback question above. Interviewers here are probing specifically how you handle disagreement with someone who has authority over your role, your review, and your career trajectory, which changes the social dynamics of pushing back. What they want to hear: you raised the disagreement directly and early rather than complaining to peers, you brought a concrete alternative rather than just objecting, and you executed fully on the final call even if it wasn&#8217;t yours.<\/p>\n<p>A story where the manager changed their mind based on your input is fine, but a story where they didn&#8217;t and you still delivered well is often more convincing, since it shows you can commit to a decision you didn&#8217;t agree with.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Give me an example of when you had to make a significant decision under time pressure with incomplete information.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The &#8220;go get it&#8221; and &#8220;bias toward action&#8221; value. A production incident where you made a call to roll back versus patch forward is the canonical answer structure. Include: what information you had, what you explicitly did not know, what made the decision time-sensitive, and how you communicated it to stakeholders in real time.<\/p>\n<p>Interviewers follow up by asking how you documented the decision and communicated the rationale afterward. Uber&#8217;s incident culture values written postmortems with explicit decision logs. If you have a postmortem story, that&#8217;s the right level of detail to bring.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Tell me about a time you had to make progress on a project with unclear or changing requirements.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Uber ships across many product surfaces at once (rides, Eats, freight, and more), and requirements genuinely shift mid-project as priorities move. The interviewer wants to hear how you created structure where none existed: did you write down your own interpretation of the requirements and get it confirmed before building, did you build in a way that limited the cost of a requirements change later, rather than just waiting for clarity to arrive.<\/p>\n<p>A weak answer here is &#8220;I asked a lot of questions.&#8221; A stronger one names the specific assumption you made explicit in writing, and what happened when that assumption turned out to be wrong.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Describe a cross-functional conflict you were involved in and how it was resolved.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Real cross-functional conflicts at Uber usually involve product wanting to ship a feature faster than the engineering team thinks is safe, or data science wanting a model in production that platform engineers believe will create infrastructure problems. Those are the kinds of conflicts interviewers recognize as authentic.<\/p>\n<p>What interviewers are assessing: whether you can represent an engineering perspective clearly to non-engineers, whether you&#8217;re willing to compromise on timeline to preserve quality, and whether you take partial ownership of the outcome even when the conflict was the other team&#8217;s call. A story that casts the other team as entirely wrong is a red flag.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Tell me about a time you had to influence a decision or a team without having formal authority over them.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Behavioral<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Common at the senior IC level. Interviewers want a story where you changed an outcome through the strength of your argument and evidence rather than through your title: getting another team to adopt a shared library, convincing a PM to cut scope, getting a peer team to prioritize a fix that benefited your service more than theirs.<\/p>\n<p>Bring data. (The stories that land best usually have a number in them somewhere, a latency figure, an incident count, a percentage of tickets, something the other side couldn&#8217;t easily argue with.) A story that&#8217;s purely about persuasive conversation, with no artifact you built to make your case, tends to feel thin in this round.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--hard\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"hard\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Hard questions<\/h2><span class=\"iq-dsec__n\">5<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Merge K sorted linked lists into a single sorted list<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Heap \/ Linked List<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Push the head node of each of the K lists onto a min-heap keyed by value. Pop the smallest node, append it to the result list, and if that node has a next node, push it back onto the heap. Repeat until the heap is empty. Time complexity is O(N log K), where N is the total number of nodes and K is the number of lists, since every pop and push touches a heap of size at most K.<\/p>\n<p>Reported in Uber phone screens and a couple of onsite loops, usually framed around merging sorted event streams rather than literal linked lists, for example combining trip-completion events arriving on K separate Kafka partitions where each partition is already ordered by timestamp. The interviewer wants the same heap-based merge; the &#8220;linked list&#8221; framing is just standing in for any set of pre-sorted streams.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Find the maximum value in every sliding window of size K across an array<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Monotonic Deque<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Maintain a deque of indices where the corresponding values are in decreasing order. For each new element, pop from the back of the deque while the back&#8217;s value is less than the current value, then push the current index. Pop from the front if the front index has fallen outside the current window. The front of the deque always holds the index of the maximum for the current window, and each index enters and leaves the deque exactly once, giving O(n) overall despite the nested-looking loops.<\/p>\n<p>Reported from Uber OAs, usually with product framing around &#8220;the maximum demand signal in every rolling five-minute window&#8221; rather than a bare array. Interviewers sometimes ask candidates to trace the deque state by hand on a small example, which is a good way to catch candidates who memorized the pattern without understanding why decreasing order has to be maintained.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\nfrom collections import deque\ndef max_sliding_window(nums, k):\n\n    dq = deque()  # stores indices, values decreasing\n\n    result = []\n    for i, num in enumerate(nums):\n\n        while dq and nums[dq[-1]] &lt; num:\n\n            dq.pop()\n\n        dq.append(i)\n        if dq[0] &lt;= i \u2013 k:\n\n            dq.popleft()\n        if i &gt;= k \u2013 1:\n\n            result.append(nums[dq[0]])\n    return result\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Find the median of two sorted arrays in logarithmic time<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Binary Search<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A straightforward merge gets you O(m+n). The interviewer is asking for O(log(min(m,n))) using binary search on the smaller array to find the correct partition point, the point where every element on the left side of both partitions combined is less than or equal to every element on the right side. Once that partition is found, the median comes directly from the four boundary elements without ever fully merging the arrays.<\/p>\n<p>This one is famous enough that Uber interviewers sometimes skip straight past the brute force and ask you to state the binary search invariant before writing a line of code. Get comfortable explaining, out loud, why moving the partition in the smaller array is safe and sufficient. It shows up across interviewing.io mock session writeups tagged Uber going back to at least 2023, and several 2025 Blind threads confirm it is still in rotation for senior backend loops.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Trapping Rain Water: compute how much water pools between building heights along a street<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Two Pointers<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Two pointers starting from both ends of the array. Track the running max height seen so far from the left and from the right. At each step, move the pointer on the side with the smaller max height inward, because the water trapped at that position is bounded by the smaller of the two maxes. Add the difference between that max and the current height to a running total. This gets you O(n) time and O(1) space, versus the O(n) space required by a prefix-max\/suffix-max array approach.<\/p>\n<p>One of the most frequently LeetCode-tagged &#8220;Uber&#8221; problems on community trackers going back several years, and it keeps showing up in 2025 and 2026 phone screens. Framed at Uber it sometimes reads as &#8220;how much rainwater accumulates between buildings along a delivery route,&#8221; same array, same algorithm. The follow-up worth preparing for: can you do it without the two auxiliary arrays? Interviewers want to see you reason about why tracking two running maxes is sufficient.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\ndef trap(height):\n\n    left, right = 0, len(height) \u2013 1\n\n    left_max, right_max = 0, 0\n\n    water = 0\n    while left &lt; right:\n\n        if height[left] &lt; height[right]:\n\n            left_max = max(left_max, height[left])\n\n            water += left_max \u2013 height[left]\n\n            left += 1\n\n        else:\n\n            right_max = max(right_max, height[right])\n\n            water += right_max \u2013 height[right]\n\n            right -= 1\n    return water\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design Uber&#039;s geospatial indexing layer: when would you choose geohash, a quadtree, or H3?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Geohash encodes latitude and longitude into a single string by interleaving bits, which makes it trivial to store and index in an ordinary key-value store like Redis. Its weakness is cell shape: geohash cells are rectangles that distort near the poles, and two points a few meters apart on either side of a cell boundary can hash to completely different prefixes, which means proximity searches need to check neighboring cells explicitly or risk missing nearby drivers.<\/p>\n<p>A quadtree recursively subdivides space into four quadrants only where density requires it, so a quiet suburb gets one large cell and a dense downtown gets many small ones. That adapts well to uneven driver density, but quadtrees are harder to shard across a distributed key-value store because cell boundaries shift with the data rather than following a fixed encoding scheme.<\/p>\n<p>Uber&#8217;s actual answer to this, published as an open-source project, is H3: a hexagonal hierarchical spatial index. Hexagons solve a problem both geohash and quadtree have, every neighbor of a hexagonal cell is equidistant from its center, so &#8220;check the 6 neighboring cells&#8221; gives a far more uniform search radius than checking the 8 neighbors of a rectangular geohash cell, where diagonal neighbors sit farther away than adjacent ones. Bring up H3 by name in an Uber system design round and explain why the hexagon property matters for neighbor search, and it signals you&#8217;ve actually looked at what the company built rather than defaulting to the generic geohash answer every other candidate gives.<\/p>\n<p>Expect a follow-up on resolution selection. H3 supports 16 resolution levels, and the practical answer is to store driver locations at a fine resolution (roughly 100 to 200 meter cells) and dynamically aggregate to coarser parent cells when a search area has too few active drivers.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--scenario\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"scenario\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Real-time scenario questions<\/h2><span class=\"iq-dsec__n\">12<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design an ETA computation service that stays accurate under changing traffic conditions<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The naive design runs a shortest-path algorithm (Dijkstra or A*) over a road-network graph weighted by historical average speeds and returns the result directly. That&#8217;s a reasonable baseline, but it&#8217;s systematically wrong in predictable ways: routing engines underestimate ETAs during unusual events (a stadium letting out, an accident) and overestimate them on roads that run faster than history suggests, a highway that was recently widened.<\/p>\n<p>The production-grade answer layers a correction model on top of the routing engine&#8217;s raw estimate rather than replacing it. The routing engine produces a base ETA from the graph. A separate model, trained on the gap between predicted and actual trip durations, applies a correction factor based on live signals: current traffic density, time of day, weather, and recent actual trip completions on nearby segments. This two-stage design mirrors what Uber has publicly described about its own ETA system, a model layered on top of the routing engine specifically to correct for the routing engine&#8217;s systematic bias, rather than trying to make the graph search itself traffic-aware in real time.<\/p>\n<p>Interviewers will ask how you&#8217;d evaluate this. The metric that matters isn&#8217;t raw accuracy on individual trips but the calibration of the error distribution, are you consistently off by the same amount in the same direction for a given route type, which tells you the correction model is missing a signal rather than just being noisy.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a rate limiter service for Uber&#039;s API gateway<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A rate limiter prevents any single caller from overwhelming downstream services. Uber&#8217;s API gateway processes hundreds of millions of RPCs per second across thousands of microservices. The design needs to be low-latency (sub-millisecond overhead), distributed (enforced across all gateway instances), and configurable per client and per endpoint.<\/p>\n<p>Algorithm choices: Token Bucket is most commonly used at Uber (Uber&#8217;s engineering blog describes their token bucket implementation for rate limiting). Fixed Window Counter is simpler but allows burst spikes at window boundaries. Sliding Window Log is the most accurate but memory-intensive at high request rates. Sliding Window Counter approximates the sliding window using two fixed window counters and is a good balance.<\/p>\n<p>Distributed enforcement: each gateway node maintains a local token bucket in memory for fast checks. Every N seconds, nodes sync their consumed token counts with a central Redis store. This means enforcement is approximate across nodes rather than exact, but the overhead of a Redis round-trip per request is unacceptable at Uber&#8217;s request rate. The approximation is acceptable for most cases; exact enforcement is only needed for payment-critical paths, which get a separate stricter limiter with Redis-based atomic decrements.<\/p>\n<p>Configuration plane: rates are stored in a config service that pushes updates to gateway nodes. This allows per-client, per-endpoint, and per-tier rate limits without a deploy. Uber&#8217;s actual rate limiting system, described on their engineering blog, uses a combination of per-service limits and per-user limits with a tiered override mechanism.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a multi-channel notification system for trip status updates<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Trip state transitions (driver assigned, driver arriving, trip started, trip completed) are the events that drive notifications, so the state machine governing a trip&#8217;s lifecycle is naturally the producer here. Each transition emits an event to a message queue, and a Notification Service consumes those events and decides what to send, to whom, and through which channel.<\/p>\n<p>Channel selection matters more than it sounds. Push is the default, cheap and fast, but it fails silently if the app is backgrounded on certain OS versions or if the user has disabled notifications. SMS is a fallback with real per-message cost, so it should trigger only for time-critical states (driver arrived) and only after a short delay confirms the push wasn&#8217;t acknowledged, not as a blind duplicate of every push.<\/p>\n<p>Deduplication is the detail that separates a working design from a broken one at scale. If the same trip-state event gets processed twice, because of a consumer retry or a Kafka rebalance, the rider shouldn&#8217;t get two &#8220;your driver has arrived&#8221; texts. An idempotency key built from trip ID plus state name, checked against a short-TTL cache before sending, handles this without needing exactly-once delivery guarantees from the queue itself.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a low-level trip state machine<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Low-Level Design<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A trip goes through a defined lifecycle: REQUESTED, DRIVER_ASSIGNED, DRIVER_EN_ROUTE, ARRIVED_AT_PICKUP, TRIP_IN_PROGRESS, COMPLETED, CANCELLED. Model this as an explicit state machine where each state defines its legal transitions and the events that trigger them. Illegal transitions should throw a domain exception, not silently succeed.<\/p>\n<p>Implementation pattern: an enum of states, a transition map (Map from state to set of valid next states), and a TripStateMachine class that validates and applies transitions. Persist current state to the database with an optimistic lock (version column) to prevent two concurrent events from double-transitioning the same trip. This shows up in Uber&#8217;s machine coding round as a 45-minute implementation exercise.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">java<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-java\">\n\npublic enum TripState {\n\n    REQUESTED, DRIVER_ASSIGNED, DRIVER_EN_ROUTE,\n\n    ARRIVED_AT_PICKUP, TRIP_IN_PROGRESS, COMPLETED, CANCELLED\n\n}\npublic class TripStateMachine {\n\n    private static final Map&lt;TripState, Set&lt;TripState&gt;&gt; TRANSITIONS = Map.of(\n\n        TripState.REQUESTED, Set.of(TripState.DRIVER_ASSIGNED, TripState.CANCELLED),\n\n        TripState.DRIVER_ASSIGNED, Set.of(TripState.DRIVER_EN_ROUTE, TripState.CANCELLED),\n\n        TripState.DRIVER_EN_ROUTE, Set.of(TripState.ARRIVED_AT_PICKUP, TripState.CANCELLED),\n\n        TripState.ARRIVED_AT_PICKUP, Set.of(TripState.TRIP_IN_PROGRESS, TripState.CANCELLED),\n\n        TripState.TRIP_IN_PROGRESS, Set.of(TripState.COMPLETED),\n\n        TripState.COMPLETED, Set.of(),\n\n        TripState.CANCELLED, Set.of()\n\n    );\n    public TripState transition(TripState current, TripState next) {\n\n        Set&lt;TripState&gt; validNext = TRANSITIONS.getOrDefault(current, Set.of());\n\n        if (!validNext.contains(next)) {\n\n            throw new IllegalStateException(\n\n                \u201cInvalid transition from \u201d + current + \u201d to \u201d + next\n\n            );\n\n        }\n\n        return next;\n\n    }\n\n}\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a distributed, sortable unique ID generator for trips (a Snowflake-style ID)<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Low-Level Design<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A single auto-increment column doesn&#8217;t scale once trip writes are sharded across multiple database instances, and a plain UUID solves uniqueness but loses time-ordering, which matters for anything that needs to scan trips chronologically without an extra index. The standard answer is a Snowflake-style ID: pack a timestamp, a machine or shard identifier, and a per-millisecond sequence counter into a single 64-bit integer.<\/p>\n<p>Bit layout is usually 41 bits for a millisecond timestamp (enough for roughly 69 years from a custom epoch), 10 bits for a machine or shard ID (supports 1,024 generators running concurrently without coordination), and 12 bits for a sequence number that resets every millisecond (4,096 IDs per generator per millisecond before you&#8217;d need to wait for the clock to advance). No central coordinator is needed once every generator has a fixed machine ID, which is the whole point, this runs independently on every shard.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\nimport time\nEPOCH = 1700000000000  # custom epoch in ms\nclass SnowflakeGenerator:\n\n    def __init__(self, machine_id):\n\n        self.machine_id = machine_id  # 0-1023\n\n        self.sequence = 0\n\n        self.last_timestamp = -1\n    def next_id(self):\n\n        timestamp = int(time.time() * 1000)\n        if timestamp == self.last_timestamp:\n\n            self.sequence = (self.sequence + 1) &amp; 0xFFF\n\n            if self.sequence == 0:\n\n                while timestamp &lt;= self.last_timestamp:\n\n                    timestamp = int(time.time() * 1000)\n\n        else:\n\n            self.sequence = 0\n        self.last_timestamp = timestamp\n\n        return ((timestamp \u2013 EPOCH) &lt;&lt; 22) | (self.machine_id &lt;&lt; 12) | self.sequence\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a data structure that returns the median of a running stream of numbers<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Two Heaps<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Maintain a max-heap for the lower half of the numbers seen so far and a min-heap for the upper half, keeping the two heaps balanced in size (never differing by more than one element). Inserting a new number means pushing it to the appropriate heap based on a comparison with the max-heap&#8217;s top, then rebalancing if the size difference exceeds one. The median is either the top of the larger heap, or the average of both tops when the heaps are equal size. Insertion is O(log n); reading the median is O(1).<\/p>\n<p>This comes up in Uber loops with real product framing attached, computing the median ETA across all trips in progress in a city, or the median fare in a surge zone over the last five minutes. One candidate reported the interviewer explicitly asking why a single sorted array wouldn&#8217;t work here (insertion into a sorted array is O(n), and the two-heap approach beats that for high-frequency streaming inserts).<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">python<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-python\">\n\nimport heapq\nclass MedianFinder:\n\n    def __init__(self):\n\n        self.small = []  # max-heap (negated values)\n\n        self.large = []  # min-heap\n    def add_num(self, num):\n\n        heapq.heappush(self.small, -num)\n\n        heapq.heappush(self.large, -heapq.heappop(self.small))\n\n        if len(self.large) &gt; len(self.small):\n\n            heapq.heappush(self.small, -heapq.heappop(self.large))\n    def find_median(self):\n\n        if len(self.small) &gt; len(self.large):\n\n            return -self.small[0]\n\n        return (-self.small[0] + self.large[0]) \/ 2\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a ride-matching system for Uber<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Start with functional requirements: rider requests a ride, system finds available drivers within a reasonable radius, matches rider to the best driver, notifies both parties, and tracks the ride through completion. Non-functional: sub-2-second matching latency, 1 million+ concurrent users, 500K+ active drivers globally.<\/p>\n<p>The geospatial matching layer is where interviewers focus most. Encode all driver locations as geohash strings (precision 6 or 7 covers roughly 1 km by 1 km cells). Store in Redis using GEOADD with the driver ID as the member and their coordinates as the value. A GEORADIUS or GEOSEARCH query returns the K nearest drivers in milliseconds without scanning the full driver set. As drivers move, update their Redis entry via WebSocket messages from the driver app through a Location Update Service.<\/p>\n<p>The matching service receives the sorted candidate list from the geospatial layer and applies secondary scoring: driver rating, estimated pickup time accounting for current traffic, vehicle type preference, and whether the driver has opted into surge areas. Dispatch a match request to the top candidate. If the driver declines or doesn&#8217;t respond within 10 seconds, move to the next candidate.<\/p>\n<p>Data flow: Rider app sends ride request to API Gateway. API Gateway routes to the Ride Request Service, which writes a pending ride record to a PostgreSQL primary. The Matching Service reads driver location data from Redis and queries the Routing Service for ETA estimates. On match acceptance, Kafka emits a RideAccepted event consumed by the Notification Service (FCM\/APNS for push), the Trip Tracking Service, and the Payment Service to pre-authorize the card.<\/p>\n<p>Interviewers will probe: &#8220;What happens if the Redis node holding driver data fails?&#8221; Answer: Redis cluster with replication and sentinel failover, plus a short degradation mode where you fall back to a broader radius search against the replicas. &#8220;What if two servers simultaneously match the same driver to two different riders?&#8221; Answer: optimistic locking on the driver availability record in Postgres, or a distributed lock via Redlock, with the losing server moving to the next candidate.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a real-time driver location tracking system at global scale<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Drivers report their GPS coordinates every 3 to 5 seconds. At 500K active drivers updating every 4 seconds on average, that&#8217;s 125K location writes per second globally. The system needs to serve those positions to riders and dispatchers with low staleness, typically under 5 seconds, and support proximity queries with sub-100ms latency.<\/p>\n<p>Architecture: driver apps maintain a persistent WebSocket connection to a Location Gateway (a stateful service with connection state in memory). The gateway fans location updates into a Kafka topic partitioned by driver ID. A Location Processor consumes from Kafka and writes to Redis Geo. Reads come either directly from Redis (for proximity queries in the matching service) or through a Location Query Service that abstracts the store.<\/p>\n<p>The pub\/sub model matters here. Polling from drivers would work but creates thundering herds at scale when many drivers are in one area. Push via persistent WebSocket lets you batch updates and control backpressure from the server side. For the rider app showing driver positions on the map, the server pushes location diffs rather than full coordinates on every tick, reducing bandwidth.<\/p>\n<p>Interviewers push on: &#8220;What&#8217;s your consistency model?&#8221; Location data is eventually consistent with a few seconds of acceptable staleness. That&#8217;s fine for showing a driver moving on a map. It&#8217;s not fine for billing, where you need to know the exact trip start time and pickup location. Those events go through a strongly consistent write path to Postgres, not through the location stream.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">go<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-go\">\n\n\/\/ LocationGateway handles WebSocket connections from driver apps\n\n\/\/ Each connection pushes location updates into Kafka\ntype LocationUpdate struct {\n\n    DriverID  string  `json:\u201ddriver_id\u201d`\n\n    Lat       float64 `json:\u201dlat\u201d`\n\n    Lng       float64 `json:\u201dlng\u201d`\n\n    Timestamp int64   `json:\u201dtimestamp\u201d`\n\n    Speed     float64 `json:\u201dspeed_kmh\u201d`\n\n}\nfunc handleDriverConnection(conn *websocket.Conn, producer kafka.Producer) {\n\n    for {\n\n        var update LocationUpdate\n\n        if err := conn.ReadJSON(&amp;update); err != nil {\n\n            \/\/ driver disconnected; mark unavailable\n\n            markDriverOffline(update.DriverID)\n\n            return\n\n        }\n\n        \/\/ validate: speed plausibility check (&gt;200 km\/h = likely GPS spoof)\n\n        if update.Speed &gt; 200 {\n\n            log.Warnf(\u201cGPS anomaly for driver %s\u201d, update.DriverID)\n\n            continue\n\n        }\n\n        msg := kafka.Message{\n\n            Key:   []byte(update.DriverID),\n\n            Value: mustMarshal(update),\n\n        }\n\n        producer.WriteMessages(context.Background(), msg)\n\n    }\n\n}\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a surge pricing engine<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Surge pricing adjusts fare multipliers in real time based on the ratio of rider demand to driver supply in a geographic area. The two primary models are rule-based (fixed multipliers when demand\/supply exceeds a threshold) and ML-driven (predictive models that factor in traffic, weather, local events, and historical patterns).<\/p>\n<p>The data flow: a Demand Signal Service aggregates open ride requests per geohash cell on a 30-second rolling window. A Supply Signal Service counts available drivers per cell from the location store. A Pricing Engine divides demand count by supply count per cell, applies the multiplier schedule, and writes the current multiplier for each cell to a replicated cache. Fare computation at ride-request time reads from this cache.<\/p>\n<p>Key trade-offs interviewers probe: Cell granularity matters. Geohash precision 5 (4.9 km by 4.9 km cells) is too coarse for dense urban areas. Precision 7 (153m by 153m) may over-fragment supply in low-density areas. A dynamic approach uses precision 6 (1.2 km by 1.2 km) as the default and aggregates to precision 5 when a cell has fewer than 5 active drivers. Boundary effects occur when a hot zone is split across cell boundaries; the fix is to check neighboring cells and apply the highest applicable multiplier.<\/p>\n<p>Fairness concerns surface in behavioral follow-ups. Interviewers sometimes ask: &#8220;How do you prevent surge from disproportionately affecting riders in low-income neighborhoods?&#8221; This is a real tension Uber has faced regulatory pressure on. A reasonable answer: cap multipliers regionally, offer fixed-price options that lock in the rate at request time, and maintain a maximum surge cap in certain markets per local regulations.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design a payment and fare settlement system for a ride-hailing marketplace<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Break the problem into three distinct flows that carry different consistency requirements: fare authorization at ride request, fare capture at trip completion, and driver payout settlement, which is typically batched. Treating all three as one atomic transaction is the mistake that gets flagged in this round; they run on different timescales and different failure domains.<\/p>\n<p>At ride request, pre-authorize (not capture) the estimated fare on the rider&#8217;s card through a PCI-compliant third-party processor. Card data never touches Uber&#8217;s own systems directly, only a tokenized reference does, which keeps the compliance scope smaller. At trip completion, the Trip Service emits a final fare amount, and the Payment Service captures the authorized hold, adjusting up or down within the processor&#8217;s allowed tolerance if the final fare differs from the estimate (tolls, wait time, route changes).<\/p>\n<p>Driver payouts don&#8217;t happen per trip in real time; they&#8217;re aggregated into a ledger and settled on a schedule (instant payout is a feature layered on top, not the default path). This is the detail interviewers want to hear reasoned through explicitly: the rider-facing payment path needs to be low latency and immediately confirmable, while the driver-facing ledger needs to be exactly-once and auditable, but doesn&#8217;t need sub-second latency. An idempotency key on every capture and settlement request, derived from the trip ID, is what prevents a retried network call from double-charging a rider or double-paying a driver.<\/p>\n<p>The follow-up almost every interviewer asks: what happens if the payment capture fails after the rider has already exited the vehicle? The trip still completes from the rider&#8217;s perspective; the charge goes into a dunning\/retry queue with the ride marked settled-pending, and repeated failures escalate to manual collection rather than blocking the rider&#8217;s app.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design the backend for a product browsing system with 50M items and 10K RPS<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>This specific scenario was reported in a December 2024 L4 onsite (e-commerce merchandise Uber sells to drivers, food delivery catalog, or similar). Requirements: 50 million items across 10,000 categories, 10K P99 requests per second, popularity-based display, offline batch processing for rankings.<\/p>\n<p>The naive approach builds a real-time ranking query on every request. At 50M items and 10K RPS, that&#8217;s a query plan that needs significant caching. The right architecture: a batch pipeline runs nightly (or hourly for high-velocity categories), computes popularity scores (views, clicks, purchases over a rolling window), and writes pre-ranked category pages to a read-optimized store. Application servers read from that store, not from the transactional database.<\/p>\n<p>Entity design matters. One candidate reported getting negative feedback for making item categories a nested tree structure in the primary DB with foreign key joins across the tree at query time. The interviewer&#8217;s concern: category tree joins at 10K RPS don&#8217;t scale. The right approach is to denormalize: store a flattened category path with each item (e.g., &#8220;electronics\/phones\/iphone&#8221;) and pre-build category index tables populated by the batch job. Search uses Elasticsearch with pre-indexed popularity scores rather than SQL.<\/p>\n<p>Cache layer: Varnish or CDN at the edge for fully static category pages (high hit rate for top categories), Redis for the popularity-ranked item lists per category (TTL of 5 to 60 minutes depending on category velocity). Invalidation on price changes goes through a write-through pattern to Redis rather than relying on TTL.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Design the order dispatch and courier matching system for a food delivery platform like Uber Eats<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">System Design<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Food delivery matching is harder than ride matching because it has three parties instead of two (rider, restaurant, courier) plus an extra dimension of time, the food needs to be ready roughly when the courier arrives, not before and not long after. A naive design that matches a courier the instant an order is placed produces couriers standing around restaurants waiting for food that isn&#8217;t ready yet.<\/p>\n<p>The dispatch logic needs a food-prep-time estimate, pulled from the restaurant&#8217;s historical average prep time for similar orders and adjusted by current order volume at that location. Matching happens in two stages: an early &#8220;soft&#8221; assignment that reserves a courier candidate without committing, and a &#8220;hard&#8221; dispatch that fires once the estimated food-ready time falls within the courier&#8217;s travel time to the restaurant. Get this wrong in either direction and you either have idle couriers burning time at the restaurant or a completed order going cold on a counter.<\/p>\n<p>Batching is the other axis interviewers probe. A single courier picking up two or three orders from restaurants near each other is more efficient than one courier per order, but only if the routing doesn&#8217;t push any single order&#8217;s delivery time past an acceptable threshold. The scoring function for a candidate courier needs to account for whether adding this order to an existing batch keeps every order in that batch within its delivery SLA, not just whether the courier happens to be geographically close.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-callout iq-callout--insight not-prose\"><div class=\"iq-callout__title\">What we&#039;ve seen across Uber loops<\/div><div class=\"iq-callout__body\"><\/p>\n<p>Candidates who practice Uber interview prep through LastRoundAI&#8217;s mock sessions show a consistent failure pattern that standard prep guides don&#8217;t capture. The system design round ends most Uber loops prematurely, and the reason is almost never that the candidate doesn&#8217;t know the algorithm. It&#8217;s that they design for a generic internet company rather than for a ride-hailing marketplace.<\/p>\n<p>Specifically: candidates who open with &#8220;I&#8217;d put the data in MySQL and add Redis caching&#8221; without naming geohash, without discussing eventual versus strong consistency by data type, and without addressing the supply-demand ratio as a first-class system concept tend to score below the bar even when their overall architecture is sound. Uber interviewers have worked with these systems. They know what the real constraints feel like.<\/p>\n<p>The second pattern we see: Uber&#8217;s behavioral round carries more weight than candidates expect. The &#8220;collaboration and leadership&#8221; round run by the hiring manager is not a warmup. Interviewers push on specific numbers (&#8220;what was the P99 latency after your change?&#8221;), specific team conflicts (&#8220;what exactly did you disagree on, and how was it resolved?&#8221;), and specific timelines. Vague STAR answers without concrete data points don&#8217;t land. Prepare your two or three strongest stories with metrics the same way you&#8217;d prepare a system design diagram.<\/p>\n<p><\/div><\/div>\n<p><script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"FAQPage\",\n  \"mainEntity\": [\n    {\n      \"@type\": \"Question\",\n      \"name\": \"How long does the Uber interview process take from application to offer?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Most candidates complete the process in four to six weeks from application to verbal offer. The online assessment is usually sent within one to two weeks of the recruiter screen. After the virtual onsite, the hiring committee review takes three to five business days.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Does Uber use CodeSignal for its coding interviews?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Yes, as of 2024 to 2026, Uber uses CodeSignal for both the online assessment and the live technical phone screen. Some teams have used HackerRank for the OA in the past, but CodeSignal is the primary platform. The environment supports Python, Java, Go, and C++.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"How important is system design for Uber interviews at different levels?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"System design is a full dedicated round for L4 and above. For L3 new grads, it is either absent or appears as a lighter architecture discussion appended to a coding round. At L5 and above, expect two system design-flavored rounds: one high-level distributed systems design and one low-level design or machine coding exercise.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"What languages does Uber accept in coding interviews?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Python, Java, and Go are the most commonly used and are well-supported by Uber interviewers. C++ is accepted but less common outside systems-adjacent roles. JavaScript is generally accepted for the OA. If the team uses Go heavily, using Go in your live screen signals genuine familiarity with the team's actual stack.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"How does Uber's behavioral round differ from Amazon's leadership principles round?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Amazon's behavioral round follows a systematic rubric mapped to named principles. Uber's round is less formulaic but just as rigorous. Uber interviewers push harder on specific data and numbers, expect real trade-offs rather than just positive outcomes, and will often turn a behavioral answer into a 15-minute technical discussion. The STAR format is still useful, but the result component needs real quantitative data.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Does Uber ask hard LeetCode problems or mostly mediums?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"The OA and live coding rounds sit mostly at medium to medium-hard difficulty. Occasional hard problems appear at senior levels. The real difficulty comes from the real-world framing and optimization pressure in follow-ups, not from the base problem difficulty alone.\"\n      }\n    }\n  ]\n}\n<\/script><\/p>\n<div class=\"iq-related not-prose\"><div class=\"iq-related__title\">Related interview guides<\/div><div class=\"iq-related__grid\"><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/stripe\"><span class=\"iq-rel__t\">Stripe Interview Questions for Software Engineers (2026)<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/amazon-sde-2\"><span class=\"iq-rel__t\">Amazon SDE-2 Interview Questions (2026): What They Actually Ask<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/meta-e5\"><span class=\"iq-rel__t\">Meta E5 Interview Questions (2026): What They Actually Ask<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/google-l4\"><span class=\"iq-rel__t\">Google L4 Interview Questions (2026): What They Actually Ask<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/system-design\"><span class=\"iq-rel__t\">System Design Interview Questions (2026): Must-Know Q&#038;A<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><a class=\"iq-rel__card\" href=\"https:\/\/lastroundai.com\/interview-questions\/backend-developer\"><span class=\"iq-rel__t\">Backend Developer Interview Questions (2026): APIs, Databases &#038; System Design<\/span><span class=\"iq-rel__arrow\" aria-hidden=\"true\">&rarr;<\/span><\/a><\/div><\/div>\n<div class=\"iq-sources not-prose\"><div class=\"iq-sources__title\">Sources &amp; further reading<\/div><ul class=\"iq-sources__list\"><li><a href=\"https:\/\/www.techprep.app\/blog\/uber-interview-process\" target=\"_blank\" rel=\"nofollow noopener\">TechPrep Uber Interview Process<\/a><\/li><li><a href=\"https:\/\/medium.com\/@laxmankumarmegwal\/uber-interview-experience-l4-sde2-backend-december-2024-da0f059c230e\" target=\"_blank\" rel=\"nofollow noopener\">Laxman Kumar Meghwal (Medium) - Uber L4 Interview December 2024<\/a><\/li><li><a href=\"https:\/\/www.educative.io\/blog\/uber-interview-process-and-questions\" target=\"_blank\" rel=\"nofollow noopener\">Educative - Uber Interview Process and Questions<\/a><\/li><li><a href=\"https:\/\/blog.codekerdos.in\/uber-sde-interview-experience-2025-complete-breakdown\/\" target=\"_blank\" rel=\"nofollow noopener\">CodeKerdos - Uber SDE Interview Experience 2025<\/a><\/li><li><a href=\"https:\/\/www.techinterview.org\/post\/3233460273\/uber-interview-guide-2026-dispatch-systems-geospatial-algorithms-and-marketplace-engineering\/\" target=\"_blank\" rel=\"nofollow noopener\">TechInterview.org - Uber Interview Guide 2026<\/a><\/li><li><a href=\"https:\/\/www.systemdesignhandbook.com\/guides\/uber-system-design-interview\/\" target=\"_blank\" rel=\"nofollow noopener\">System Design Handbook - Design Uber<\/a><\/li><li><a href=\"https:\/\/ophyai.com\/blog\/company-guides\/uber-interview-guide\" target=\"_blank\" rel=\"nofollow noopener\">OphyAI Uber Interview Guide<\/a><\/li><\/ul><\/div>\n","protected":false},"excerpt":{"rendered":"<p>A backend engineer who went through Uber&#8217;s loop in late 2024 described the experience this way: &#8220;Every problem had a hidden layer. They&#8217;d give you a standard graph traversal problem but frame it as &#8216;there are a million drivers and you need to find the 10 nearest ones in under 50 milliseconds.&#8217; You couldn&#8217;t just&#8230;<\/p>\n","protected":false},"author":5,"featured_media":1723,"comment_status":"open","ping_status":"closed","template":"","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"tags":[],"class_list":["post-989","iq","type-iq","status-publish","has-post-thumbnail","hentry"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.8 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Uber Interview Questions (2026) | LastRoundAI<\/title>\n<meta name=\"description\" content=\"Real Uber SWE interview questions for 2026: coding, system design (ride-matching, geospatial, surge pricing), behavioral. Verified from candidate reports.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/lastroundai.com\/interview-questions\/uber\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Uber Interview Questions (2026) | LastRoundAI\" \/>\n<meta property=\"og:description\" content=\"Real Uber SWE interview questions for 2026: coding, system design (ride-matching, geospatial, surge pricing), behavioral. Verified from candidate reports.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/lastroundai.com\/interview-questions\/uber\" \/>\n<meta property=\"og:site_name\" content=\"LastRound AI\" \/>\n<meta property=\"article:modified_time\" content=\"2026-07-19T05:24:09+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-uber-og.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"630\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"26 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/uber\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/uber\",\"name\":\"Uber Interview Questions (2026) | LastRoundAI\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/uber#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/uber#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/iq-uber-og.png\",\"datePublished\":\"2026-06-29T10:14:17+00:00\",\"dateModified\":\"2026-07-19T05:24:09+00:00\",\"description\":\"Real Uber SWE interview questions for 2026: coding, system design (ride-matching, geospatial, surge pricing), behavioral. Verified from candidate reports.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/uber#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/uber\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/uber#primaryimage\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/iq-uber-og.png\",\"contentUrl\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/iq-uber-og.png\",\"width\":1200,\"height\":630,\"caption\":\"Uber interview questions \u2014 LastRoundAI\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/uber#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/lastroundai.com\\\/blog\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Interview Questions\",\"item\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Uber Interview Questions (2026): What They Actually Ask\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/\",\"name\":\"LastRound AI\",\"description\":\"Interview Assistant prep, tech careers and AI tools\",\"publisher\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#organization\",\"name\":\"LastRound AI\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png\",\"contentUrl\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png\",\"width\":400,\"height\":400,\"caption\":\"LastRound AI\"},\"image\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Uber Interview Questions (2026) | LastRoundAI","description":"Real Uber SWE interview questions for 2026: coding, system design (ride-matching, geospatial, surge pricing), behavioral. Verified from candidate reports.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/lastroundai.com\/interview-questions\/uber","og_locale":"en_US","og_type":"article","og_title":"Uber Interview Questions (2026) | LastRoundAI","og_description":"Real Uber SWE interview questions for 2026: coding, system design (ride-matching, geospatial, surge pricing), behavioral. Verified from candidate reports.","og_url":"https:\/\/lastroundai.com\/interview-questions\/uber","og_site_name":"LastRound AI","article_modified_time":"2026-07-19T05:24:09+00:00","og_image":[{"width":1200,"height":630,"url":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-uber-og.png","type":"image\/png"}],"twitter_card":"summary_large_image","twitter_misc":{"Est. reading time":"26 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/lastroundai.com\/interview-questions\/uber","url":"https:\/\/lastroundai.com\/interview-questions\/uber","name":"Uber Interview Questions (2026) | LastRoundAI","isPartOf":{"@id":"https:\/\/lastroundai.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/lastroundai.com\/interview-questions\/uber#primaryimage"},"image":{"@id":"https:\/\/lastroundai.com\/interview-questions\/uber#primaryimage"},"thumbnailUrl":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-uber-og.png","datePublished":"2026-06-29T10:14:17+00:00","dateModified":"2026-07-19T05:24:09+00:00","description":"Real Uber SWE interview questions for 2026: coding, system design (ride-matching, geospatial, surge pricing), behavioral. Verified from candidate reports.","breadcrumb":{"@id":"https:\/\/lastroundai.com\/interview-questions\/uber#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/lastroundai.com\/interview-questions\/uber"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lastroundai.com\/interview-questions\/uber#primaryimage","url":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-uber-og.png","contentUrl":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-uber-og.png","width":1200,"height":630,"caption":"Uber interview questions \u2014 LastRoundAI"},{"@type":"BreadcrumbList","@id":"https:\/\/lastroundai.com\/interview-questions\/uber#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/lastroundai.com\/blog"},{"@type":"ListItem","position":2,"name":"Interview Questions","item":"https:\/\/lastroundai.com\/interview-questions"},{"@type":"ListItem","position":3,"name":"Uber Interview Questions (2026): What They Actually Ask"}]},{"@type":"WebSite","@id":"https:\/\/lastroundai.com\/blog\/#website","url":"https:\/\/lastroundai.com\/blog\/","name":"LastRound AI","description":"Interview Assistant prep, tech careers and AI tools","publisher":{"@id":"https:\/\/lastroundai.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/lastroundai.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/lastroundai.com\/blog\/#organization","name":"LastRound AI","url":"https:\/\/lastroundai.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lastroundai.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/06\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png","contentUrl":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/06\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png","width":400,"height":400,"caption":"LastRound AI"},"image":{"@id":"https:\/\/lastroundai.com\/blog\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq\/989","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq"}],"about":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/types\/iq"}],"author":[{"embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/comments?post=989"}],"version-history":[{"count":4,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq\/989\/revisions"}],"predecessor-version":[{"id":1850,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq\/989\/revisions\/1850"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/media\/1723"}],"wp:attachment":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/media?parent=989"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/tags?post=989"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}