Interview experience
Urban Company Interview Questions and Answers (2026)
Overview
Section titled “Overview”Urban Company’s loop is unusually design-heavy for a fresher process - after a genuinely hard coding assessment, both technical interviews are low-level-design rounds rather than a DSA-then-system-design split.
Urban Company interview process at a glance
Section titled “Urban Company interview process at a glance”| Round | Duration | What it tests |
|---|---|---|
| Online Coding Assessment | ~90 min | 3 medium-hard DSA problems (need ~2 fully correct) |
| LLD Round 1 | ~60 min | Data-structure-flavoured design (e.g. LRU-cache-style task manager) |
| LLD Round 2 | ~60 min | Marketplace/two-sided design (e.g. Uber Carpool-style system) |
| Technical HR | 30-45 min | Resume questions, motivation, genuineness |
Online Coding Assessment
Section titled “Online Coding Assessment”Roughly 90 minutes for 3 problems at medium-hard difficulty. Candidates describe it as a real bar rather than a screen - you generally need at least 2 problems fully, correctly solved (not just attempted) to move on.
Common questions
- Medium-hard array/string problems under time pressure
- A problem requiring an optimal (not brute-force) solution to pass all test cases
- Edge-case-heavy DSA problems (trees, graphs, or DP depending on the drive)
LLD Round 1 - data structure design
Section titled “LLD Round 1 - data structure design”A self-contained object-oriented design problem close to a data-structure exercise. Candidates report being asked to design a task manager that can add tasks and evict the least-frequently-used one - conceptually adjacent to an LRU cache.
Common questions
- Design a task manager supporting add, complete, and evict-least-frequent operations
- Justify your class structure and how you’d extend it (e.g. add priorities)
- Discuss time complexity of your core operations
- Handle edge cases - ties in frequency, empty state, capacity limits
LLD Round 2 - marketplace design
Section titled “LLD Round 2 - marketplace design”Shifts to Urban Company’s actual two-sided marketplace shape. A reported prompt is designing an “Uber Carpool”-style system - listing requirements, the classes involved, and how they interact, without needing full working code.
Common questions
- Design a carpool/ride- or service-matching system: list requirements and core classes
- How would you match a customer to an available service professional by location and rating
- How do you model booking state - pending, confirmed, cancelled, completed
- What happens when a matched professional cancels or goes unavailable mid-booking
Round-by-round narratives are on the Urban Company interview experience page.
Technical HR round
Section titled “Technical HR round”A lighter closing round focused on your resume and genuine motivation - candidates report interviewers explicitly valuing honest, specific answers over rehearsed or “bookish” ones.
Common questions
- Tell me about yourself and why Urban Company
- Walk me through a project on your resume in your own words
- What are you passionate about outside of work, and why
- Tell me about a time you balanced the needs of two different groups (e.g. customers and service partners)
Sample answer frameworks for each of these are on the Urban Company HR interview questions page.
Why Urban Company leans so hard on LLD
Section titled “Why Urban Company leans so hard on LLD”Urban Company is a managed, two-sided marketplace - it matches customers to vetted service professionals by location, ratings, and availability, then standardises pricing, quality, and payments itself rather than leaving that to the two sides. That shape shows up directly in its interviews: instead of one DSA round and one system-design round, both technical interviews are low-level design exercises, and the second one is explicitly framed around matching and allocation (a ride/service-booking-style system) rather than a generic e-commerce or CRUD prompt. Candidates who can reason concretely about state transitions (booking, cancellation, reassignment) tend to do better than those who only know design-pattern names.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How do you design an LRU cache with O(1) get and put?
Combine a hash map with a doubly linked list. The hash map maps key to the list node holding that key’s value, giving O(1) lookup; the doubly linked list keeps nodes in recency order with the most recently used at the head. On get, look the node up and unlink-then-reinsert it at the head. On put, insert at the head, and if size exceeds capacity, remove the tail node and delete its key from the map. Both operations are O(1) because a doubly linked list lets you unlink a known node in constant time without scanning. Java’s LinkedHashMap with accessOrder = true implements exactly this and you can override removeEldestEntry.
Q: How would you design a task manager that evicts the least-frequently-used task?
LFU needs a count per key plus a way to find the minimum count in O(1). Keep three structures: a map from key to value and frequency, a map from frequency to a doubly linked list (or LinkedHashSet) of keys at that frequency, and an integer minFreq. On access, remove the key from its current frequency bucket, increment its count, and append it to the next bucket; if the old bucket was minFreq and is now empty, increment minFreq. On eviction, drop the oldest key in the minFreq bucket, which resolves frequency ties by recency. All operations are O(1). The tie-breaking rule is the part interviewers actually probe, so state it explicitly.
Q: How do you match a customer to a nearby service professional efficiently?
A naive scan computing distance to every professional is O(n) per request and does not scale. Instead index professionals by a spatial key - geohash, S2 cell, or Uber’s H3 hexagons - so a lookup becomes a hash lookup on the customer’s cell plus its ring of neighbours, narrowing to a small candidate set. Then rank that candidate set by a score combining travel time, rating, skill match, and current load, and lock the chosen professional with an atomic compare-and-set so two bookings cannot grab the same slot. Keep availability in an in-memory store like Redis with a TTL so stale professionals fall out automatically.
Q: How would you model booking state transitions in an object-oriented design?
Model Booking with an explicit status enum - PENDING, CONFIRMED, IN_PROGRESS, COMPLETED, CANCELLED - and never let external code set the field directly. Instead expose intent methods such as confirm(), start(), and cancel() that validate the current state before transitioning, throwing on an illegal move like completing a cancelled booking. This is the State pattern: each transition is defined in one place, so adding RESCHEDULED later touches one table of allowed edges rather than scattered if-statements. Persist transitions as an append-only event log so you can audit why a booking ended up where it did, and enforce the transition in the database with a conditional update so concurrent cancel and confirm requests cannot both win.
Q: What is the difference between composition and inheritance in a design round?
Inheritance expresses an is-a relationship and binds the subclass to the parent’s implementation at compile time, so a change to the parent ripples into every subclass - the fragile base class problem. Composition expresses has-a: the class holds a reference to a collaborator behind an interface and delegates to it, which can be swapped at runtime. For a marketplace design, a PricingStrategy or MatchingStrategy injected into a booking service is composition, and it lets you vary pricing per city without a subclass explosion. The usual guidance is to prefer composition and reserve inheritance for genuine substitutable subtypes that satisfy the Liskov Substitution Principle.
Q: Which SOLID principle matters most in an LLD interview, and why?
The Single Responsibility Principle and the Dependency Inversion Principle carry the most weight. SRP means each class has one reason to change - so a Booking class holds booking state while a separate NotificationService sends messages and a separate PaymentProcessor charges the card, which is what interviewers look for when they say your classes should have clean boundaries. DIP means the high-level booking service depends on a PaymentGateway interface, not on a concrete gateway class, so you can add a provider or stub one in tests without touching the service. Naming the principle is worth little on its own; showing the class list that follows from it is what scores.
Q: How do you prevent two customers from booking the same professional slot at once?
This is a lost-update race. The simplest correct fix is an optimistic conditional write: UPDATE slots SET status = 'BOOKED', booking_id = ? WHERE slot_id = ? AND status = 'AVAILABLE', then check the affected-row count - if it is zero, someone else won and you retry with another slot. Alternatively take a pessimistic lock with SELECT ... FOR UPDATE inside a transaction, which is simpler to reason about but holds a row lock and hurts throughput under contention. A unique constraint on (professional_id, start_time) is a good backstop because the database rejects the duplicate even if application logic has a bug. Optimistic control is usually preferred here since actual collisions are rare.
Q: For 3 medium-hard OA problems in 90 minutes, how do you choose an approach under time pressure?
Read all three first and spend about two minutes classifying each by pattern - two pointers or sliding window for contiguous-subarray questions, hash map for frequency or complement lookups, BFS for shortest hops, DP when subproblems overlap. Then start with the one whose pattern you recognise fastest to bank a full solve, since Urban Company reports needing roughly two fully correct, not three partials. Check the input bounds before coding: n up to about 10^5 rules out a quadratic loop and points at O(n log n) or better, while n up to 20 hints that bitmask or exponential search is fine. Write the brute force only if you are stuck with under fifteen minutes left, because partial credit beats an unfinished optimal attempt.
Frequently asked questions about Urban Company interviews
Section titled “Frequently asked questions about Urban Company interviews”What is the Urban Company interview process for freshers?
Urban Company’s SDE loop typically runs 4 stages: 1. Online Coding Assessment (~1.5 hours) - 3 problems of medium-hard difficulty; candidates generally need to clear at least 2 fully to advance. 2. Low-Level Design Round 1 (~1 hour) - design an in-memory system (e.g. a task manager that evicts the least-frequently-used task, LRU-cache-adjacent). 3. Low-Level Design Round 2 (~1 hour) - a marketplace-shaped design problem (candidates report an ‘Uber Carpool’-style system: list requirements, classes, and interactions, no working code required). 4. Technical HR round - resume-based questions plus motivation and genuineness checks. Total duration is roughly 2-3 weeks.
What questions are asked in Urban Company interviews?
The OA is 3 medium-hard DSA problems under real time pressure. The two LLD rounds ask you to design working object-oriented systems from scratch - one closer to a data-structure problem (an LRU-cache-style task manager), one closer to Urban Company’s actual marketplace shape (a carpool/ride-matching-style system with customers and providers). The closing round is lighter - resume questions and genuine motivation, not bookish answers.
How many rounds are there in the Urban Company interview?
Urban Company typically runs 4 stages: an online coding assessment, two low-level-design interviews, and a technical HR round. Some drives merge or skip a round depending on team and hiring cycle - confirm the exact structure with your recruiter.
How should I prepare for Urban Company interviews?
Practice medium-hard DSA under time pressure (you need at least 2 of 3 OA problems fully correct to advance). For the LLD rounds, practice designing systems with clean class boundaries end-to-end - not just naming patterns, but actually listing classes, their responsibilities, and interactions - for both a data-structure-flavoured problem (LRU-style eviction) and a marketplace-flavoured one (two-sided matching, like a carpool or booking system).
Why does Urban Company ask marketplace/two-sided design questions?
Because Urban Company’s product is a two-sided, managed marketplace - matching customers to service professionals by location, ratings, and availability, then standardising quality, pricing, and payments in between. Design prompts like an Uber-Carpool-style system test whether you can reason about matching, allocation, and state (bookings, cancellations, availability) rather than a generic single-sided CRUD app.
How hard is Urban Company’s online assessment?
Candidates describe it as genuinely hard - 3 medium-hard problems in about 1.5 hours, with roughly 2 needing to be fully correct (not just attempted) to advance to interviews. Treat it like a competitive-programming round, not a warm-up screen.