Urban Company Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Urban Company: it is a marketplace and operations company at heart, matching service professionals with customers.

• The business runs on real-time matching: a customer books a salon slot at 7pm, a nearby pro has to be assigned, paid, and rated.
• That means payments, scheduling, logistics, and trust/safety all at scale.
• The interview rewards engineers who ship maintainable code and reason about real-world edge cases, not whiteboard tricks.
• The machine-coding round is where the strongest signal lives, and it flips more decisions than any other.

2Getting the call (the part most guides skip)#

Three doors open interviews here. Referrals, off-campus applications, and campus hiring at target engineering colleges.

A referral is the strongest lever.

• It moves your resume to the top of the pile and often skips the generic online assessment.
• Find people on LinkedIn who joined in the last year (they still have referral-bonus incentive and remember the pain of applying cold).
• Send a short, specific note: one line on why that team, one line on a relevant project, resume attached.
• Keep it to four sentences: who you are, the one project that maps to their team, your years and stack, and a direct ask.

Resume rules. One page. Lead every bullet with impact and a number. Compare these two:

• Weak: "Worked on backend APIs for the booking module."
• Strong: "Built a slot-booking API in Java/Spring handling 2,000 req/min; cut p99 latency from 480 ms to 110 ms by adding a Redis read-through cache."

The second one tells a reviewer you can own a service, measure it, and improve it, exactly the mindset a marketplace company screens for.

• The pattern is always: action verb, what you built, the scale it ran at, the measurable delta.
• If a bullet has no number, either find one or cut it.

ATS keywords. Mirror the job description honestly.

• For backend roles: Java, Spring Boot, microservices, REST, SQL/NoSQL, Redis, Kafka, AWS, Docker, plus design terms like caching, sharding, consistency.
• Only list what you can defend in an interview.
• If your resume says Kafka and you cannot explain consumer groups and offset commits, that line becomes a trap in the deep-dive, not an asset.

How people actually get shortlisted.

• Off-campus: a strong GitHub with a real deployed project (not tutorials) plus a quantified resume. A live URL, a README that explains the architecture, and commit history that shows iteration beat ten forked tutorial repos.
• On campus: clear the online coding test (usually 2-3 DSA problems on a timed platform), and your DSA fundamentals carry you into the loop.
• Experienced hires: the odds improve a lot when your resume shows you owned a service end to end, design through on-call. The words "on-call" and "production incident" do real work: they signal you have shipped to real users and felt the consequences.

3The loop at a glance#

How the order shifts by level.

• Exact sequence varies by team and level.
• New grads lean toward DSA plus one design-lite round.
• SDE-2 and above always get a full system design and a stronger machine-coding bar.

Respect the bar-raiser.

• Usually a senior engineer from a different team whose only job is to protect the hiring bar.
• They can veto an offer even if your team interviewers liked you.
• So do not coast on the last round assuming it is a formality.

4The coding / technical rounds, patterns, not problems#

Urban Company reuses a tight set of patterns, not obscure trivia. Master these and most problems feel familiar:

• Arrays & strings: two pointers, sliding window (longest substring, max window sum), prefix sums, interval merging.
• Hashing: frequency maps, grouping, two-sum family, subarray-sum-equals-k.
• Stacks & queues: next greater element, valid parentheses, monotonic stack, LRU-style problems.
• Trees & recursion: BFS/DFS, level order, lowest common ancestor, binary search tree validation, path sums.
• Graphs: BFS/DFS, topological sort, shortest path (Dijkstra/BFS), connected components, cycle detection. Relevant because scheduling and matching are graph problems.
• Heaps / priority queues: top-k, merge k sorted lists, median of a stream.
• Dynamic programming (medium): knapsack variants, longest common/increasing subsequence, grid paths, coin change.
• Binary search: on arrays and on the answer space (minimize max, allocation problems).

Difficulty.

• Mostly LeetCode Medium with one Hard-leaning problem in the second round.
• They care more about a correct, well-reasoned Medium than a half-finished Hard.
• A clean Medium with stated complexity, a dry-run, and good variable names outscores a Hard where you got the idea but never closed the bugs.

How to practice.

• Do ~120-150 problems organized by the patterns above, not randomly.
• For each, write the brute force, state its complexity, then improve it and restate complexity.
• Rehearse out loud. The interview is as much about narration as code.
• Track the patterns you keep missing in a simple sheet. If sliding-window trips you three times, that is your next session, not another random Medium.

How to win the round.

1. Clarify first. Restate the problem; ask about input size, duplicates, empty inputs, and output format. Input size is the tell for target complexity: n up to 1e5 means roughly O(n log n), n up to 1e9 means binary search or math.
2. Think out loud. Say your approach before coding: "I'll use a sliding window because we need the longest valid substring." State the approach and its complexity before you type, so the interviewer can redirect you early if you are heading somewhere slow.
3. State complexity. Give time and space for your approach, and again after optimizing. This is a direct signal they grade on.
4. Write clean code. Good names, small helper functions, no magic numbers. Name the variable windowStart, not i2. Marketplace teams review a lot of code and they notice readability.
5. Test it. Dry-run one normal case and one edge case (empty, single element, all duplicates). Catching your own bug beats the interviewer catching it, every single time.

5Machine-coding / low-level design, the round that decides it#

This is Urban Company's signature round, and where many otherwise-strong candidates lose the offer.

• You get a real-world problem and 60-90 minutes to build a working, well-structured solution in your language of choice.
• No frameworks: pure classes, interfaces, and an in-memory store, running on the clock.
• No database, no Spring, no autocomplete-driven boilerplate.

Classic prompts in this style:

• An in-memory booking/slot system for service professionals (add availability, book a slot, prevent double-booking, cancel, reschedule).
• A ride/service matching or dispatch system (assign nearest available pro to a request).
• A splitwise/expense sharing system (users, groups, balances, settle-up).
• A parking lot, elevator, or vending machine simulator.
• A rate limiter or notification service with pluggable channels (SMS/email/push).
• A cab/food ordering cart with pricing, discounts and order states.

A framework that scores well:

1. Nail requirements (5 min). List the entities and operations. Write down in-scope vs out-of-scope and say it aloud. For a booking system: book, cancel, reschedule, prevent double-booking in scope; payments and notifications out unless asked. Stating this stops you building the wrong thing.
2. Model the domain (10 min). Define classes and their responsibilities: User, Slot, Booking, BookingService. Favor composition and single-responsibility classes. One class, one reason to change.
3. Use interfaces for anything that varies. Pricing strategy, matching strategy, notification channel: code to an interface so a new variant is a new class, not an if branch. When the interviewer says "now add surge pricing," you add a SurgePricingStrategy class and wire it in; you do not touch the booking logic at all. That moment is the whole round.
4. Write working code, incrementally. Get the happy path running first, then handle edge cases (double-booking, invalid input, concurrency notes). A running partial system beats a perfect design with no code.
5. Keep it clean and testable. Separate concerns: data classes, service/logic layer, and a small main/driver that exercises it. Add a couple of assertions or printed test cases.

Here is the skeleton graders want to see for the booking prompt, interfaces for the varying parts, a thin service that orchestrates:

interface MatchingStrategy {
    Professional assign(Slot slot, List<Professional> available);
}

class NearestProStrategy implements MatchingStrategy {
    public Professional assign(Slot slot, List<Professional> available) {
        // pick closest free pro; swappable without touching BookingService
        return available.stream()
            .filter(Professional::isFree)
            .min(Comparator.comparingDouble(p -> p.distanceTo(slot)))
            .orElse(null);
    }
}

class BookingService {
    private final MatchingStrategy matcher;
    private final Map<String, Booking> bookings = new ConcurrentHashMap<>();

    BookingService(MatchingStrategy matcher) { this.matcher = matcher; }

    synchronized Booking book(Slot slot, List<Professional> pros) {
        if (slot.isTaken()) throw new SlotUnavailableException(slot.getId());
        Professional pro = matcher.assign(slot, pros);
        if (pro == null) throw new NoProAvailableException();
        slot.markTaken();
        Booking b = new Booking(slot, pro);
        bookings.put(b.getId(), b);
        return b;
    }
}

Three things to notice in that code:

• The strategy is an interface, so matching logic swaps cleanly without touching the service.
• book is synchronized and the slot check plus mark is one atomic step, so two callers cannot double-book.
• The exceptions are specific, not a bare return null.

That is the difference between a merge and a "please refactor."

What graders reward:

• Extensibility: can I add a new feature without rewriting?
• Correct state handling and thread-safety awareness.
• Code you would actually accept in a pull request.

What sinks candidates:

• One giant method, no classes, global mutable state.
• Spending 40 minutes designing on paper with nothing running.
• If you have not run your code by the 35-minute mark, you are already losing.

System design (for SDE-2 and above) runs alongside this. Use a standard flow:

• Clarify functional and non-functional requirements.
• Back-of-envelope scale (QPS, storage).
• API contract.
• High-level architecture (clients, load balancer, services, DB, cache, queue).
• Data model.
• Deep dive on one or two hard parts (hot partitions, consistency, idempotent payments).
• Bottlenecks and trade-offs.

Expect prompts drawn from their world: a service-booking platform, a nearby-professional search, a notification/reminder system, a ratings & reviews service, or a payments/wallet flow. Always discuss consistency vs availability, caching strategy, and how you would shard the primary datastore.

For the booking platform, volunteer the hard parts before you are asked:

• Slot booking must be idempotent and conflict-free: a unique constraint on pro plus slot time, or an optimistic lock.
• Geo search for nearby pros wants a geohash or quadtree index, not a full scan.
• Payments need an idempotency key so a retried request never double-charges.

Name those three and you have shown you understand the actual domain, not a generic CRUD app.

6Behavioral & culture fit#

Urban Company's culture, in practice, centers on ownership, customer obsession, bias for action, raising the bar, and transparency/candor.

• They are building trust in a two-sided marketplace, so they look for engineers who care about both the customer and the service professional.
• Move fast without being sloppy, and own outcomes rather than tickets.
• Treat "ownership" as the headline value. Stories where you drove something end to end, including the messy parts, land best.
• The signal they hunt for is "I owned the outcome even when it was not strictly my job." A story where you chased a bug across three teams beats one where you shipped a feature you were assigned.

Prepare 5-6 STAR stories (Situation, Task, Action, Result) covering:

• A hard technical problem you owned.
• A conflict you resolved.
• A failure and what you learned.
• A time you improved quality or reliability.
• A moment you went beyond your role for the customer.

How to tell them:

• Every result needs a number.
• Spend most of each answer on Action, that is where the interviewer learns what you actually did.
• Keep Situation to two sentences, and never let the Result be "it went well."

One full worked STAR example:

• Situation: Our checkout service was timing out during evening peak, and about 6% of bookings failed at the payment step.
• Task: As the on-call owner, I had to cut failures below 1% within the sprint without a full rewrite.
• Action: I traced it to synchronous calls to a slow third-party payment API blocking threads. I introduced an async queue for payment confirmation, made the status endpoint idempotent so retries were safe, added a circuit breaker with a fallback "payment processing" state, and backfilled alerting on the queue depth.
• Result: Peak-hour payment failures dropped from 6% to 0.4%, p99 checkout latency fell by ~55%, and we recovered an estimated ₹12-14 lakh/month in otherwise-abandoned bookings. The idempotency pattern was later reused by two other teams.

Why that example works:

• It is specific, shows ownership, and names a real fix.
• It ends with a hard number plus lasting impact.
• The last sentence (two other teams reused the pattern) pushes it from "solved a problem" to "raised the bar," exactly the value a bar-raiser is scoring.

7Your prep plan#

4-week plan (ideal):

• Week 1: Core DSA patterns, arrays, strings, hashing, stacks, two pointers, sliding window. ~6 problems/day, narrate each.
• Week 2: Trees, graphs, heaps, binary search, intro DP. Start a daily 45-min timed problem to build speed.
• Week 3: Machine-coding. Build 4-5 full mini-systems (booking, splitwise, rate limiter, parking lot) in 75 min each. Refactor one afterward and note how you'd extend it.
• Week 4: System design (if SDE-2+), mock interviews, and write out all STAR stories. Re-solve your weakest 20 DSA problems.

2-week plan:

• Days 1-5: Patterns blitz, 8 problems/day across arrays, hashing, trees, graphs, DP.
• Days 6-9: Two machine-coding builds and one system-design walkthrough per day (verbal is fine).
• Days 10-12: Timed mocks, one per day, mixed DSA + design.
• Days 13-14: STAR stories, resume walkthrough, light review. Sleep well before the loop.

2-day crash plan:

• Day 1: 15-20 Medium problems across the top patterns; build one machine-coding problem end to end (booking system).
• Day 2: One system-design template memorized; write 4 STAR stories with numbers; re-run your machine-coding build and clean it up. Review complexity for every data structure.

8Why people get rejected at Urban Company#

1. Machine-coding code was unstructured: one huge method, no classes, not extensible. The single most common reason strong coders fail here.
2. Solved DSA but never stated complexity, or ignored edge cases, signaling shallow understanding.
3. Silent problem-solving: correct answer, no narration, so the interviewer could not assess reasoning.
4. Froze on ambiguity instead of clarifying. Marketplace problems are deliberately underspecified to see if you ask.
5. Behavioral answers with no ownership or numbers: "the team did X" instead of "I did X and it moved Y by Z%."
6. Over-engineered the design: reached for Kafka and sharding on a problem that needed a clean data model and one cache, missing the "pragmatic shipper" signal they want.

The thread running through all six.

• They are hiring someone to maintain real production code.
• Anything that reads as "I can pass a puzzle but I would be hard to work with" sinks the offer.
• Clean, communicated, pragmatic beats clever and silent every time.

9The offer, comp & negotiation#

Compensation is competitive for the Indian market and typically combines base, a joining/retention bonus, and ESOPs, with the equity portion growing meaningfully at SDE-2 and above.

• SDE-1 often lands around ₹20-32 LPA total.
• SDE-2 around ₹35-55 LPA total, depending on level, team, and your current market.
• Senior and staff offers add significant equity.
• The headline number blends base, bonus, and ESOPs, so ask the recruiter to break it out. A ₹40 LPA offer with ₹28 base reads very differently from one with ₹35 base.

Negotiation tips:

1. Anchor with a competing offer or a strong current package. This is the most reliable lever. Share a concrete number, not a vague "I expect more."
2. Negotiate the whole package, not just base. If base is capped by band, ask for more ESOPs or a larger joining bonus, which recruiters often have room on.
3. Be collaborative and specific. "Based on my competing offer and the SDE-2 scope here, I'm targeting ₹X total, can we get there?" A respectful, data-backed ask almost never costs you the offer and frequently improves it.

One more. Do not accept on the call. "Thank you, I am excited, can I review the written offer and come back in two days" is a complete sentence, and that pause is often where the recruiter finds another lakh or two.

10FAQ#

Q: How hard is the DSA bar? A: Mostly LeetCode Medium with one Hard-leaning problem in the deeper round. Clean, complete Mediums with stated complexity beat half-finished Hards.

Q: What matters most in the machine-coding round? A: A working, well-structured, extensible solution. Use classes and interfaces, handle edge cases, and get the happy path running early. Readable code you'd ship is the goal.

Q: Do I need system design as a new grad? A: Usually only a light version. Full system design is expected from SDE-2 upward. Knowing basics (caching, load balancing, SQL vs. NoSQL) still helps.

Q: Which language should I use? A: Whatever you're fastest in, Java, C++, Python, or Go are all fine. For machine-coding, pick the language whose OOP you know cold, the clock does not forgive fumbling with syntax.

Q: How long does the process take? A: Typically 2-4 weeks. A referral and prompt scheduling can compress it; offers usually follow within a week of the final round.

Want a personalized, dated prep plan that maps these rounds to your interview date and current skill level? Build one and walk in knowing exactly what to practice each day.