The Staff Engineer Geospatial Interview: Nearby Search, Hot Regions, and Fresh Location

Nearby is a query contract, not a grid cell

A delivery rider is close to a restaurant but falls just across a spatial-cell boundary. A search that checks only the restaurant’s cell misses the rider. A larger cell fixes that example while flooding a dense city query with candidates. Start your geospatial interview with this boundary problem.

Define “nearby” precisely: within a radius, nearest eligible objects, travel time or a service polygon. Those are different queries. A straight-line distance can help select candidates while being a poor final proxy for arrival time across a river or restricted road. Ask which meaning the hypothetical product needs.

Use an illustrative delivery dispatch service. Clarify location update frequency, acceptable staleness, the number of candidates required and whether availability or permissions must filter results. Decide how the UI should describe an incomplete or stale result. This guide’s workload examples are assumptions to rehearse, not a claim about a particular company’s production traffic.

Write correctness requirements before choosing an index: eligible candidates within the requested region are considered; returned distances use the agreed definition; stale location is visible; a dense region cannot exhaust shared serving capacity. Make the freshness and latency targets explicit interview questions rather than inventing a universal benchmark.

Use the right coordinates and an exact final predicate

PostGIS ST_DWithin supports distance-based filtering, with geometry and geography variants whose units and behavior differ. ST_Distance likewise distinguishes planar geometry from geography calculations. State your coordinate representation and units. A value in longitude and latitude is not automatically a distance in meters.

ST_Transform changes a geometry into another coordinate reference system; assigning a reference identifier is a different operation. Use that distinction to avoid a subtle modeling mistake. In the interview, say where location arrives, how it is validated and which representation the index and final calculation use.

Validate latitude and longitude ranges, missing coordinates and location timestamps. Specify whether an update outside expected bounds is rejected or quarantined. Do not allow a malformed location to become a silent default point that appears in every nearby query. Keep source time and ingestion time separately when delayed devices are possible.

The PostGIS spatial-indexing workshop explains using bounding boxes to select candidates and then an exact spatial test. That two-stage reasoning is broadly useful: a coarse filter reduces work, while the final predicate enforces the query contract. An index hit is a candidate, not always the complete answer.

Test geographic boundaries deliberately. Include cell edges, the antimeridian, high-latitude coordinates and an empty result. The required cases depend on your product’s supported regions. A design confined to one city can state that scope; a global service should not quietly assume the geometry of a small local map.

Choose cell resolution from workload and query shape

H3 describes hierarchical spatial indexing with a hexagonal grid and pentagons. Its resolution tables show that cell counts, areas and edge lengths change with resolution and that cell areas vary. Avoid treating an average cell area as the exact geometry of every cell on Earth.

A finer resolution reduces some candidate sets but increases the number of cells touched by a wider query. A coarser resolution reduces lookup fan-out while increasing filtering work in dense areas. Describe both costs. Pick a proposed resolution based on query radii, density and update workload, then explain how you would measure it.

Query all cells needed to cover the requested region, including adjacent cells where appropriate, and apply the final distance or polygon predicate. Do not rank “nearest” by cell number or assume points in the same cell are closer than points outside it. Spatial indexing and final relevance are separate stages.

Redis GEOSEARCH supports radius or box searches and optional sorting or limits, with documented tradeoffs such as early termination options. PostGIS’s nearest-neighbor operator supports index-assisted distance ordering under its documented semantics. Choose a mechanism based on the intended query rather than presenting one as universally faster.

Give availability and permissions their own filtering step. A rider can be spatially nearby but unavailable, assigned elsewhere or outside the requesting tenant’s scope. Decide whether that predicate runs before ranking and limit selection. Returning the nearest ten and discarding nine afterward can leave an unnecessarily poor result set.

Plan for density rather than average geographic load

An illustrative stadium exit can concentrate updates and queries in a handful of cells. Even if traffic is balanced across the world overall, that local region can become a hot key or partition. Calculate work for the dense case: candidate count, update rate, cell fan-out and the ranking cost per query.

Separate geographic locality from physical partition assignment. You may retain a spatial cell as an index key while distributing its members across subpartitions. Explain how a query discovers and merges those subpartitions. Splitting a hot region trades concentrated work for fan-out; the design needs a bound and an observable merge budget.

Consider the difference between slowly changing places and rapidly changing participants. Restaurants might fit a persistent spatial database; mobile riders may need a separate fresh-location projection. Name which store is authoritative for identity and assignment, and which is derived for discovery. Recovery should rebuild the projection without losing business ownership.

Use admission control when a request is too expensive. Limit radius, result count or query rate according to product needs, and return a meaningful response. A broad unrestricted query can be an accidental denial of service even when every individual coordinate is valid.

Cache cautiously. A cache keyed only by coarse area can return stale availability or inappropriate tenant data. Include the authorization and query dimensions needed for correctness, and use a freshness policy the product can explain. Popular-location caching is useful only when it preserves the promised semantics.

Treat location and pagination as changing state

Attach source timestamp, ingestion timestamp and an update sequence where available. Reject or handle out-of-order updates according to the source contract. A delayed device report should not automatically replace a newer accepted location. Give each discovery result enough freshness information for the next stage to make a decision.

Choose a policy for stale participants: exclude them, mark them unknown or use a conservative fallback. A dispatch request should revalidate availability and assignment in the authoritative system before committing work. Spatial discovery can suggest candidates without owning the final assignment invariant.

Pagination needs a stable ordering definition. If candidates move between requests, a cursor over live distance order can produce duplicates or omissions. Decide whether the product needs a snapshot, a bounded search session or simply an explicitly live result list. Carry the relevant query and ordering identity in the cursor.

Store only the location precision and history needed for the product. Give access to detailed traces a deliberate purpose and retention policy. Operator dashboards can show coarse region load without exposing every participant’s journey. A design review should account for both discovery correctness and the sensitivity of location data.

Measure update-to-search visibility, age of returned positions, candidate filtering cost and work by hot region. Keep a distinction between zero eligible results and incomplete results caused by overload or projection lag. Without that distinction, an empty list can hide a broken discovery pipeline.

Practice a query across the edge and the hotspot

Rehearse a search centered on a cell edge, then repeat it in a dense region with stale participants. Explain the cells searched, the candidates selected, the exact predicate, the eligibility filter and the final assignment check. That trace demonstrates more than an impressive map diagram.

Change one requirement at a time: radius search becomes nearest-neighbor search; static places become moving objects; one tenant becomes many; or local support becomes global. Say which assumption breaks and which component must change. Treat every capacity number in the exercise as an explicit input or calculation.

A useful closing proposal is: “I will use a coarse spatial index for discovery, enforce exact query semantics on candidates, revalidate mutable business state and isolate dense-region work.” State the freshness compromise the user will see when the pipeline falls behind.

The strongest geospatial answer keeps geography, freshness and business eligibility connected. A spatial cell organizes the search; it does not decide whether a candidate is close enough, current enough or available. Practice that distinction in Interview Copilot and make the boundary-crossing rider the test that keeps your design honest.