Uber Frontend Interview
What frontend candidates typically face at Uber — rounds, scale/maps flavored design, coding bar, and a prep plan. Composite/unofficial.
- interview-experience
- uber
Composite, unofficial guidance based on publicly shared candidate reports and common Uber hiring patterns for frontend / mobile-web / UI engineering roles. Processes vary by org (Rider, Driver, Eats, Freight, Maps), level, and year — always confirm with your recruiter. Not affiliated with Uber.
Typical loop
| Stage | Focus | Format |
|---|---|---|
| Recruiter | Role, level, team interest | Call |
| Technical screen | Coding (JS/TS or general) | Shared editor |
| Onsite / virtual loop | Coding ×2, JS/UI depth, system design (level-dep), behavioral | 4–5 interviews |
| Team matching / hiring review | Packet | Varies |
Uber products are latency-sensitive, map-heavy, and used on flaky mobile networks. Strong candidates connect UI decisions to reliability and scale, not only pretty components.
Coding rounds
Expect medium (occasionally harder) DSA in JavaScript/TypeScript or your stronger language:
- Arrays, hashes, intervals, graphs/BFS
- Trees; string parsing
- Design-flavored: LRU, rate limiter, iterators
Prep anchors: Two Sum, Merge Intervals, Number of Islands, LRU Cache, Binary Search.
Delivery: clarify → approach → code → dry-run → complexity. Narrate; silent perfection scores weaker.
JavaScript, React & mobile web
Common depth areas:
- Event loop, promises, abortable fetch (Event Loop)
- React rendering and list performance (Reconciliation, List virtualization)
- Maps/list hybrid UIs: virtualization, expensive re-renders
- Offline / poor-network UX; retry with backoff
- Internationalization and RTL for global markets
Machine-coding style practice: Infinite Scroll Feed, Autocomplete Search Box.
System design (frontend)
Mid+ levels: design a product Uber cares about:
- Live trip tracking map + bottom sheet
- Driver/eater multitasking home
- Fare estimator + payment methods
- Eats restaurant menu + cart
- Realtime status updates over flaky networks
Structure:
- Users, goals, constraints (battery, network, GPS noise)
- Component tree and state ownership
- Map SDK vs DOM list coordination
- Realtime (polling vs websocket), reconciliation of stale events
- Caching, optimistic UI, failure modes
- Perf budgets and a11y
Style reference: Design YouTube, Design a News Feed.
Behavioral
Expect ownership, ambiguity, and cross-team conflict stories. Quantify impact (conversion, latency, crash rate). Use STAR with your technical decisions.
Difficulty by level (sketch)
| Level | Bar sketch |
|---|---|
| Junior / L3-ish | Solid coding + fundamentals |
| Mid | Coding speed + design of a mobile-web surface |
| Senior | System design depth, reliability stories, mentorship |
Preparation plan (6–8 weeks)
- Weeks 1–2: JS + React fundamentals teach-back
- Weeks 3–5: Daily timed DSA; log patterns
- Weekends: One machine-coding build + one maps/feed design outline
- Weeks 6–7: Mocks (coding + design); story bank
- Week 8: Light review; sleep; logistics
Common mistakes
- Ignoring network/offline in design rounds
- Treating maps as a black box with no state model
- Skipping DSA because “Uber is product”
- No metrics in behavioral stories
Takeaways
- Uber frontend loops still grade algorithms.
- Differentiate with realtime + mobile performance literacy.
- Practice talking through unreliable network failure modes.
- Confirm exact loop with the recruiter — teams differ.