Uber Frontend Engineer Interview Questions
The short answer
Uber's frontend engineer loop starts with a timed CodeSignal assessment, then moves through a JavaScript specialisation round, one or two live UI builds, a frontend system design round, and a behavioural interview. Unlike most frontend loops it keeps genuine data structures and algorithms in the mix, and interviewers habitually push a working answer toward what happens at Uber's traffic.
Uber's frontend loop keeps a real algorithms round alongside the UI builds, and almost every answer eventually turns into a question about scale.
Or skip ahead and have your answer scored — free, no account needed.
The Uber Frontend Engineer interview process
Uber is one of the few companies where a frontend candidate still faces real algorithmic problems as well as component work. The other thing to expect is the scale pivot: you will build something that works, and the interviewer will ask what happens when the data arrives every second, or when there are ten thousand rows, or when the connection drops mid-trip. The interesting part of an Uber answer is almost never the first version.
Typically 4 to 6 weeks from the online assessment to a decision.
CodeSignal Assessment
Roughly 35 minutes, two coding questions plus multiple-choice
- Data structures and algorithms under a hard timer
- Breadth of frontend knowledge in the multiple-choice section
- Finishing rather than perfecting
The multiple-choice questions cover general frontend concepts, so revising browser and CSS fundamentals pays off even though the coding half is algorithmic.
Tech Specialisation Round
About 60 minutes, live JavaScript
- Clean, modular JavaScript without framework help
- Asynchronous programming and the event loop
- Modern ES6 fluency and DOM manipulation
This is where implement-your-own questions live: promises, event emitters, throttling, and similar utility work.
UI Coding Round
60 minutes, building a working component live
- State modelling for interactive behaviour
- Event handling and cleanup
- Whether the component survives new requirements
Reported tasks include poll widgets, chat-style live-updating interfaces, drag-and-drop boards, and grid puzzles where cells must deactivate in reverse order of activation.
Frontend System Design
60 minutes, discussion and diagramming
- Real-time data strategy: polling, websockets, or streams
- Rendering large or continuously updating datasets
- Offline, retry, and degraded-network behaviour
Uber surfaces are live by nature, so a design that assumes a request-response page will be pushed hard.
Behavioural and Values
45 to 60 minutes
- Ownership of outcomes rather than tasks
- Working across teams under time pressure
- Honest handling of something that went wrong
What Uber grades across the whole loop
- Algorithmic ability that has not decayed behind framework work
- JavaScript internals: event loop, async, closures
- Designs that hold up when data arrives continuously
- Ownership in the behavioural round
10 Uber Frontend Engineer interview questions
These are drawn from what frontend engineer candidates report being asked at Uber. Under each one is what Uber is testing and what a strong answer actually contains — not what technique to use.
JavaScript internals
The specialisation round is where Uber checks you can build the things a framework normally gives you. Expect to write utilities from scratch and explain the event loop while you do it.
“Implement throttle, then explain how it differs from debounce and when you would use each.”
Why they ask it
Uber's interfaces receive continuous position and price updates, so rate-limiting is not academic, it is how the map stays usable.
What a good answer contains
A correct closure over a timestamp or timer, a concrete example for each, and the observation that a live location marker wants throttle while a search box wants debounce.
“Implement a simple event emitter with on, off, and emit.”
Why they ask it
It tests data structure choice, closure handling, and whether you think about removal and memory leaks rather than only the happy path.
What a good answer contains
A Map of event names to handler sets, off that actually removes the right handler, safe iteration when a handler unsubscribes during emit, and a note about leaks if listeners are never removed.
“Explain the output order of a snippet mixing setTimeout, a resolved promise, and synchronous logs.”
Why they ask it
The event loop, macrotasks, and microtasks are graded explicitly in this round and are the fastest way to distinguish deep from surface knowledge.
What a good answer contains
Naming the call stack, microtask queue, and macrotask queue, giving the exact order, and explaining why a promise callback runs before a zero-millisecond timeout.
“Write a function that fetches from an unreliable endpoint and retries with exponential backoff.”
Why they ask it
Uber clients run on bad mobile connections, so retry behaviour is part of ordinary frontend work rather than an edge case.
What a good answer contains
A retry limit, growing delays with some jitter, an abort path, and a distinction between errors worth retrying and errors that are not.
UI coding
Live component builds. The reported tasks are usually stateful puzzles rather than static layouts, because the grading is about how you model state.
“Build a grid of cells that light up when clicked, then deactivate one by one in the reverse order they were activated.”
Why they ask it
A reported Uber task. It looks like a toy and is really a test of whether you pick the right data structure for ordered state.
What a good answer contains
Holding activation order in a stack or array rather than trying to derive it from the grid, a clean deactivation sequence driven by timers with proper cleanup, and no direct DOM mutation outside the framework.
“Build a chat-style panel that appends messages arriving from a live source and stays scrolled to the newest one.”
Why they ask it
It mirrors a real Uber surface and combines continuous updates, scroll behaviour, and performance in one small task.
What a good answer contains
Only auto-scrolling when the user is already at the bottom, batching rapid updates so rendering does not thrash, keys that stay stable, and cleanup of the subscription on unmount.
“Build a sortable, filterable table and then make it work with ten thousand rows.”
Why they ask it
This is the scale pivot in its purest form: the first version is easy and the follow-up is the actual interview.
What a good answer contains
Correct sort and filter first, then windowing or virtualisation, memoising the derived rows so sorting does not rerun on every keystroke, and being explicit about what you would measure before optimising further.
Frontend system design and behavioural
Where Uber's scale obsession is most visible, plus the ownership round that closes the loop.
“Design the frontend for live driver tracking on a trip in progress.”
Why they ask it
It is the definitive Uber frontend problem and cannot be answered with a request-response page.
What a good answer contains
Choosing websockets or server-sent events with a stated reason, interpolating between position updates so the marker moves smoothly, throttling redraws, and a plan for what the rider sees when the connection drops.
“How would you make the initial map view usable on a slow connection?”
Why they ask it
Perceived performance on poor networks is a genuine Uber constraint in most of its markets.
What a good answer contains
Splitting the map bundle out of the critical path, rendering a usable skeleton first, deferring non-essential tiles and overlays, and naming the metric you would watch, such as time to interactive.
“Tell me about a time you owned something that went wrong in production.”
Why they ask it
Ownership is graded directly and Uber wants to see you stay with a problem rather than hand it off.
What a good answer contains
Your specific decision that caused or missed it, what you did in the first hour, what the users experienced, and the durable change you made afterwards rather than a promise to be more careful.
A worked answer, with the structure showing
This is written to be spoken, not read. Do not memorise it — take the shape and put your own experience through it.
The question
“Design the frontend for live driver tracking on a trip in progress.”
Frontend engineer, five years' experience, previously on a logistics dashboard product.
Frame the constraint — 20 seconds
The thing that shapes this whole design is that the rider is holding a phone, on a cellular connection, staring at the screen while anxious. So my two constraints are that updates have to feel continuous, and the interface has to stay honest when the network is not cooperating.
Transport — 25 seconds
I would use a websocket rather than polling. Polling at the frequency this needs would mean a request every second or two per active rider, which is a lot of connection overhead for data that is being pushed anyway. I would keep a polling fallback for networks that block websockets, at a lower frequency, and treat it as degraded rather than equivalent.
Rendering — 30 seconds
Position updates arrive irregularly, so I would not move the marker straight to each new coordinate, because that looks like teleporting. I would interpolate between the last known position and the new one over the expected interval, and drive it from requestAnimationFrame rather than a React state update per frame, so I am not rerendering the tree sixty times a second. The map layer keeps its own imperative handle.
Failure behaviour — 25 seconds
When updates stop arriving, I would not freeze the marker and pretend everything is fine, because that is the state where riders panic. After a few seconds without an update I would show a quiet reconnecting indicator and stop interpolating, so the last known position is honest rather than a guess. On reconnect I would jump to the true position rather than animating a long stale path.
What I would measure — 15 seconds
I would watch time from trip start to first position render, the rate of reconnects per trip, and dropped frames on low-end devices, because that last one is where this design would fail first.
Why it works at Uber
- Starts from the user's real situation rather than from the technology, which is what separates a design answer from a list of tools.
- Chooses a transport and gives the reason, including an explicit fallback, instead of naming websockets and moving on.
- Handles the degraded case directly, which is the follow-up Uber interviewers reliably push toward.
- Ends with measurable signals and names where the design would break first, showing engineering judgment rather than confidence.
Free · no account needed
Say your answer out loud. Get it scored.
Reading about the structure is not the same as saying it. Answer “Tell me about a time you owned something that went wrong in production.” the way you would in the room, and get a score plus three specific fixes. Aim for 90-120 seconds.
This browser cannot record audio. .
Practise these out loud with AI feedback
Reading the questions is not the same as answering them. Paste the actual Uber job posting and your CV, and prepare.fyi builds the twenty questions that loop is most likely to ask — then you answer them out loud, with a live AI interviewer and a scored breakdown of every answer.
What candidates get wrong in this loop
Assuming the frontend loop means no algorithms.
Uber keeps a genuine data structures and algorithms component, including a timed CodeSignal round, so candidates who prepared only components get caught out early.
Fix: Keep arrays, maps, recursion, and complexity analysis sharp alongside your React practice, and rehearse under a timer.
Reaching for a library in the specialisation round.
The round exists to see you build throttle, an emitter, or a retry loop yourself. Naming lodash answers a different question than the one asked.
Fix: Practise writing the common utilities from scratch and be ready to explain the closure and timer behaviour inside them.
Stopping when the first version works.
Uber interviewers reliably pivot to scale. A candidate who treats a working table as finished never gets to show the part that is actually being graded.
Fix: As soon as it works, say out loud what breaks at ten thousand rows or at one update per second, and start there before you are prompted.
Designing only the happy path in system design.
Uber's product is used on unreliable mobile networks, so a design with no answer for a dropped connection is incomplete rather than optimistic.
Fix: Budget a third of your system design answer for degraded states: reconnection, stale data, retries, and what the user is shown meanwhile.
Bringing a behavioural story where the failure belonged to someone else.
The round grades ownership specifically, and a story about a teammate's bug demonstrates the opposite of what is being measured.
Fix: Prepare one incident that was unambiguously yours, including what users saw and the guardrail you added afterwards.
Uber Frontend Engineer interview: frequently asked questions
- Does the Uber frontend interview include LeetCode-style questions?
- Yes. Uber is unusual among frontend loops in keeping real data structures and algorithms, including a timed CodeSignal assessment with coding questions alongside multiple-choice frontend questions.
- What framework does Uber use in the frontend interview?
- React is the common expectation for component rounds, but the specialisation round is deliberately framework-free and tests plain JavaScript: closures, the event loop, async behaviour, and DOM work.
- How long is the Uber frontend engineer interview process?
- Typically 4 to 6 weeks from the online assessment through the onsite loop to a decision, though scheduling across time zones can stretch it.
- What is the Uber frontend system design round like?
- A 60-minute discussion about a live Uber surface such as trip tracking or a continuously updating feed. It focuses on real-time data strategy, rendering performance, and what the interface does when the network degrades.
- What should I prepare for the Uber tech specialisation round?
- Practise implementing utilities from scratch such as throttle, debounce, an event emitter, and a retry with backoff, and be able to explain the event loop, microtasks, and macrotasks while you write.
Other roles at Uber
Uber
Software Engineer interview questions
Backend and general engineering loops: coding, system design, and behavioural rounds.
Uber
Data Engineer interview questions
SQL at depth, data modelling, and pipeline design for messy production data.
Uber
Product Manager interview questions
Product sense, metrics and analytics, prioritisation, and execution rounds.
The questions every Uber round opens with
Each has the structure, example answers, and the same free grader.
Go deeper
How this page was put together
Compiled from public candidate reports, Uber’s own published material, and interview write-ups, last checked 7 August 2026. Interview loops change and vary by team, level and office — treat this as a strong prior, not a script. If something here no longer matches what you were sent, tell us and we will correct it.