Urban Company-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
A home-services marketplace sells time, not goods, and time has awkward properties: it is consumed in intervals, those intervals cannot overlap for one professional, and every booking carries travel and buffer around it. Machine coding rounds in the style of Urban Company are built on interval arithmetic and availability, which makes them a distinct family from inventory-based commerce rounds.
The second layer is matching by skill and geography: a professional qualifies for a service category, works in certain pin codes, and publishes a weekly availability pattern from which concrete slots are generated. This page covers the commonly reported format, the evaluation criteria, and Gronex repositories with the same booking mechanics.
What a Urban Company-style machine coding round looks like
Expect 90–120 minutes to build a slot-booking slice: define professionals with skills, service areas, and weekly availability; expose bookable slots for a given service, date, and area; book one; and handle cancellation and rescheduling. The statement typically adds a service duration and a buffer between jobs, which is what turns a slot list into an interval problem.
Overlap detection is the core, and the half-open interval is the specific skill. A job from 10:00 to 11:00 must not block a job starting at 11:00, but with a fifteen-minute buffer it must block one starting at 11:10. Interviewers test the boundary in both directions, plus a booking fully contained within another, plus two bookings that share only an endpoint. A single overlap predicate used everywhere is the difference between passing and debugging live.
Rescheduling is where partial designs fall apart, because it is a release and a claim that must be atomic. The new slot may be unavailable, in which case the original must survive untouched. Candidates who implement reschedule as cancel-then-book lose the booking whenever the second half fails, and that is precisely the sequence the reviewer runs. Recurring bookings and a cancellation-window fee are the usual follow-ups.
How you’re evaluated
One overlap predicate
Half-open interval logic implemented once, with buffers folded in, and used by availability, booking, and rescheduling alike.
Availability generation
Concrete slots derived from a weekly pattern plus exceptions and existing bookings — never a hand-maintained list.
Atomic rescheduling
Release and re-claim as one operation, so a failed reschedule leaves the original booking intact.
Eligibility matching
Skill, service area, and availability applied as filters with deterministic ranking among the qualified professionals.
Common mistakes that fail this round
- Writing overlap checks inline at three call sites, then getting two of them subtly different.
- Treating intervals as closed, so back-to-back bookings are rejected and the demo looks broken.
- Ignoring buffer and travel time, which makes every generated slot technically available and operationally impossible.
- Implementing reschedule as cancel-then-book, losing the booking when the new slot is taken.
- Generating availability from a stored slot list that drifts out of sync with the bookings that consumed it.
Quick tips for the room
- Implement overlap once as [start, end) and call it everywhere.
- Fold the buffer into the interval, not into the caller.
- Derive slots from availability patterns; never store a slot table.
- Make reschedule one atomic operation with a rollback-free failure path.
How to prepare
Write the overlap predicate and its tests first — same endpoint, contained, identical, adjacent-with-buffer — and refuse to duplicate it anywhere. Then generate slots from a pattern rather than storing them, and implement reschedule as a single guarded operation. Those three decisions cover the majority of the rubric in this round style.
The repositories below drill the same logic: the shared-calendar problem is slot booking under concurrency, the hotel-booking problem is the half-open interval predicate in its classic form, the expiring-holds problem adds the reservation timeout, the CRM assignment problem covers skill-based routing with escalation, and the free seat-reservation problem is the claim-and-release baseline.
Practice problems in the Urban Company-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Shared Calendar Slot Booking
Slot booking under concurrency: overlap rules, participant availability, and no double-booking.
Open the challenge →Hotel Room Booking System
The half-open interval predicate in its purest form, plus cancellation that truly releases every night held.
Open the challenge →Reservation with Expiring Holds
Holds that expire between selection and payment, released exactly once under contention.
Open the challenge →Skill-Based Assignment & Escalation
Routing by capability with deterministic ranking, load rules, and escalation on timeout.
Open the challenge →Seat Reservation System
Reserve, cancel, and list availability deterministically — the claim-and-release baseline. Free to try.
Open the challenge →FAQ
Were these problems asked at Urban Company?
No. They are Gronex originals in the style of services-marketplace rounds — the kind of problem asked in rounds like Urban Company’s. Gronex is not affiliated with Urban Company.
Why are half-open intervals such a big deal?
Because they decide whether back-to-back bookings are legal. Model time as [start, end) and adjacency works naturally; model it as closed and you either reject valid bookings or double-book a boundary — and the reviewer tests both directions.
Should slots be stored or generated?
Generated, from an availability pattern minus existing bookings. A stored slot table drifts the moment a booking or a cancellation is missed, and explaining why you avoided it is a strong design point.
Is concurrency required for this round?
The build is usually single-threaded, but two customers booking the same slot is the guaranteed question. Being able to show that your book() is an atomic check-and-claim — as the shared-calendar problem forces — is the expected answer.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Urban Company. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from Urban Company.