Site Reliability Engineer Interview Experience at Urban Company – 2026

This coding round has two problems: a graph-based connected-components problem on a grid, solvable with BFS marking visited cells to count distinct regions, and a script-writing problem to parse a server metrics log and identify any host whose CPU utilization stayed above a threshold for a continuous period exceeding a given duration. Tracking a running start-timestamp per host whenever utilization crosses the threshold, clearing it when utilization drops back down, is the expected approach.

Candidates are asked to design the infrastructure for real-time provider-availability matching, where the system needs to reflect a service provider's live availability (accepting a booking, currently on a job, offline) with low latency across a large number of concurrent bookings citywide. An in-memory availability cache keyed by provider ID, updated via events rather than polling the source of truth on every booking attempt, with a periodic reconciliation job to correct for any dropped events, is a strong direction — since a booking system that occasionally shows a provider as available when they've just gone offline is a worse failure mode than a slightly stale cache that self-corrects within seconds.

The engineering manager asks about a time a candidate had to balance building automation tooling against just fixing an immediate operational problem manually, and how that decision was made. A strong answer describes a recurring manual step that ate significant time weekly, and how the case was made to invest a few days automating it despite short-term pressure to keep manually shipping features, framing the payback period explicitly rather than asking for the time on faith.