Skip to content
Interview Questions

Urban Company Interview Experience 2026

Overview

How Urban Company fresher and off-campus SDE interviews actually run - loops differ by year. Campus reports emphasise a hard OA plus two LLD interviews and sometimes a VP-level managerial round; 2025 off-campus referrals often skip the big OA for live DSA + entity-modelling LLD + HR. Synthesized from public write-ups into round tables and outcome notes - treat this as a prep map, not a script.

Eligibility (candidate-reported): 7.0+ CGPA / 70% through 10th, 12th, and graduation; CS/IT; no active backlogs.

Fresher package ballpark (candidate-reported): ₹18–25 LPA. Confirm on your offer letter. Work location is commonly Gurugram.

How Urban Company differs from generic startup SDE loops

  • LLD / entity modelling is a recurring decision round (sometimes two LLD interviews on campus).
  • Year variance is large: campus Day 0 hard OA vs 2025 referral-style live DSA without the big OA.
  • VP/managerial closes appear in some campus reports after technicals.
  • Marketplace/domain framing helps, but LLD clarity decides more offers than buzzwords.

Round-wise process

Track Typical stages What they test
Campus SDE-1 (2021 write-up) 1.5 hr OA + 3 × 1 hr interviews 3 hard problems; LFU task manager; driverless cab LLD; VP DSA + resume
Campus SDE (public write-up) OA + live DSA + LLD + tech HR DP-heavy OA; Uber Carpool LLD; genuine motivation
Off-campus 2025 Referral screen + 3 rounds Merge intervals + topo sort DSA; BookMyShow LLD; culture HR
Off-campus 2024 4 rounds DSA; e-commerce LLD; caching HM; production Q&A

Confirm your drive mail - Urban Company merges or skips stages by team.

Real interview experiences

These are rewritten from public candidate write-ups, not invented composites. Details differ by campus and year.

Experience 1: SDE-1, on-campus (Day 0 offer)

Source: Urban Company (formerly UrbanClap) Interview Experience for SDE 1 (On-Campus) - GeeksforGeeks

The drive opened with a pre-placement talk by the SVP of Engineering and the VP of Product, then one coding test and three hour-long interviews.

  • Round 1 - Coding test (1.5 hours): 3 problems, medium to hard. The candidate solved two of three and still advanced.
  • Round 2 - Low-level design (1 hour, with an SDE-II): design a task manager that can add tasks and delete the least frequently used ones. Solved with OOP plus set-backed structures. Note this is essentially an LFU-cache problem dressed as a product feature.
  • Round 3 - Low-level design (1 hour, with an engineering manager): design an app for driverless cab booking against a given requirement list. Graded on class structure, data members and member functions - not on running code.
  • Round 4 - Managerial (1 hour, with the VP of Engineering): resume walkthrough covering internships and a computer-vision project, then a DSA problem on finding pairs across multiple arrays, generalised to k arrays. The write-up flags that generalising your solution when the interviewer widens the problem was the thing being tested.
  • Outcome: Offer on Day 0.

Takeaways

  • What decided it: Advancing on 2/3 hard OA solves, then LFU-style task manager and driverless-cab LLD, plus generalising multi-array pairs when the VP widened the problem.
  • Common fail: Stopping at the first pair-sum formulation; treating LLD as optional for freshers.
  • How to practise: OOP LFU/task-manager design; cab-booking class diagrams; practise “now make it work for k arrays” follow-ups.

Experience 2: SDE, on-campus

Source: Urban Company Interview Experience for SDE (On-Campus) - GeeksforGeeks

  • Round 1 - Online assessment (HackerEarth): 3 medium-to-hard problems. The candidate’s own advice was to prioritise dynamic programming in prep.
  • Round 2 - Coding interview (1 hour): a single DP problem, live. Interviewer described as approachable and receptive to thinking out loud.
  • Round 3 - Low-level design: design an Uber Carpool system - list requirements, then the classes and how they interact. Explicitly no working code required.
  • Round 4 - Technical HR: resume-driven, plus what the candidate is actually interested in and where they want to go. Advice from the write-up: answer honestly rather than from a script, and know every line of your own resume.
  • Outcome: Selected.

Takeaways

  • What decided it: DP-heavy OA and live DP coding, then Uber Carpool LLD graded on class structure (no running code required), plus honest resume-driven tech HR.
  • Common fail: Scripted motivation answers; weak DP prep for HackerEarth OAs.
  • How to practise: Timed DP sets; speak requirements → classes → interactions for a carpool design without coding.

Common thread: Urban Company weights low-level / OOP design more heavily than most fresher loops - two of the four rounds in both accounts are design, and the prompts are consistently marketplace-shaped (cab booking, carpooling, task scheduling). Practising class-diagram-level design out loud matters at least as much as DSA volume here, and DP shows up repeatedly on the coding side.

Experience 3: SDE-1, off-campus 2025 (Medium)

Source: Urban Company SDE-1 Interview Experience Off-Campus - 2025

Referral after resume screen; HR phone screen on internships, location, and expected CTC.

  • Round 1 – DSA (1 hr): Two problems - merge intervals variant and topological sort application. Discuss brute force first, then code optimised solutions and run custom tests.
  • Round 2 – LLD (1 hr): Design BookMyShow - functional/non-functional requirements, entities, relationships, API list; code optional due to time.
  • Round 3 – HR / culture (1 hr): Prior workplaces, situational judgement, differences across domains and cultures.

Outcome: Strong hire on DSA and HR; lean hire on LLD (candidate still progressed).

Takeaway: Off-campus loops may replace the triple-problem OA with a focused live DSA round but keep entity-modelling LLD as the differentiator.

Experience 4: SDE-1, off-campus (Medium - not selected)

Source: Urban Company SDE-1 Interview Experience - Atul Kumar

Four rounds after LinkedIn outreach.

  • Round 1 – DSA: Cleared with strong performance.
  • Round 2 – LLD: E-commerce backend - product listing, cart, payment page, notification service; SOLID, schema, and interactive whiteboarding; interviewer rated above expectations.
  • Round 3 – Hiring manager: Deep project review; server-side vs client-side caching - candidate admitted limited hands-on cache implementation; insightful discussion but mixed depth.
  • Round 4: Production scalability/reliability questions - partial answers.

Outcome: Rejected despite excellent rounds 1–2; feedback cited gaps on caching and production ops.

Takeaway: LLD alone does not carry if later rounds expose missing production fundamentals - study cache-aside, idempotency, and basic reliability patterns.

Experience 5: SDE, off-campus backend (Medium)

Source: Urban Company SDE-1 Backend Interview Experience - Hrithik Roushan

  • Online assessment: Two problems - islands / grid DFS and DAG-style reasoning.
  • Round 1 – Problem solving: Both questions solved with explanation.
  • Round 2 – LLD: Hotel management - rooms, bookings, customers; implement availability check, reservation, payment flows; edge cases and extensibility.
  • Later rounds: Projects, internships, situational behavioural.

Outcome: Rejected (reason not shared publicly).

Takeaway: LLD prompts extend beyond ride-sharing - inventory + booking + payment systems appear frequently; practise coding core methods, not only class lists.

Pre-interview checklist (Urban Company)

  • Confirm whether your loop includes a large OA or starts at live DSA + LLD
  • Drill DSA mediums daily; keep one hard warm for campus OA years
  • Practise 2 LLD sketches (booking/marketplace entities, status machines)
  • Prep Why Urban Company with one marketplace ops concrete point
  • STAR stories for ownership and ambiguity for HR/managerial

Questions that come up often

Coding / technical

  1. Top-K frequent elements - heap or bucket sort
  2. Shortest path / islands on a grid - BFS or DFS
  3. Merge intervals and scheduling variants
  4. Topological sort for dependency ordering
  5. Multi-array pair sum generalised to k arrays (VP round report)
  6. LLD: LFU/LRU task manager, Uber Carpool, BookMyShow, e-commerce cart/checkout, hotel booking
  7. Marketplace matching - geospatial indexing, slot locking, partner no-show handling
  8. Production follow-ups: caching, idempotent payments, peak-traffic readiness

HR / behavioural

  1. Why this product?
  2. Working with unclear requirements
  3. On-call or weekend comfort
  4. Relocation

Practical tips for Urban Company

  • Clear the screening round first. Timed practice beats last-minute topic hopping.
  • For domain questions, explain marketplace matching in plain language, inputs, outputs, what breaks at scale.
  • OOPs and SQL still open a lot of Urban Company panels. Do not skip fundamentals.
  • HR answers should be concrete. One story with a result beats five slogans.
  • If you do not know something, say so and outline how you would find out.

HR interview

After technical rounds, Urban Company usually closes with a short HR / hiring-manager conversation: motivation, location, notice period, and a couple of behavioural stories. Prepare those answers on the dedicated page rather than cramming them into this hub.

Sample answers for high-frequency questions

Use these as frames, not scripts - interviewers probe follow-ups.

Q. How do you design an LRU cache with O(1) get and put?
A. 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?
A. 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. 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?
A. 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?
A. 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.

Tips from successful candidates

Assessment tips

  • Confirm the current Urban Company pattern from the drive mail before practising old papers
  • Finish one problem or section fully before starting the next
  • Revise the fundamentals listed in the round table on this page

Interview tips

  • Narrate trade-offs; expect “why” after every answer
  • Only list projects you can defend under follow-ups
  • Prepare 3-4 STAR stories for behavioural prompts

HR tips

  • Know why Urban Company, not just why the industry
  • Be clear on location / notice period / higher studies
  • Practise answers on the dedicated HR page

Sources

These links are research inputs we used to map campus vs off-campus LLD-heavy loops - not copied page mirrors. We reorganized reports into process tables, outcome notes, and prep takeaways for Urban Company.

Urban Company hub

HR interview questions

Placement papers

Preparation guide

Similar companies

Swiggy · Zomato · Flipkart · Paytm · Ola · Meesho