Zillow Coding Interview Questions: Map Search, Home Values, and Listing Data

Most people meet Zillow through a map. They drag it to a neighborhood, set a price range, and expect the pins and the list beside them to update at once - showing homes that are genuinely still available. Behind that simple experience sit three hard problems: answering location queries quickly across a very large set of homes, estimating what homes are worth while being honest about the uncertainty, and merging listing data from many sources so it stays accurate as homes move from for sale to pending to sold.

This guide covers the process candidates commonly describe, the topics worth prioritizing, the domain themes that make natural material for coding and design rounds, representative problem types, and a two-week plan. We describe patterns rather than claiming to know specific questions: question sets rotate, and fluency with the underlying ideas is what carries into the room.

How the Zillow interview process tends to run

The stages below reflect what candidates commonly report, as an outline rather than a promise. The number and order of rounds, the tools, and whether there is an online assessment all vary by team and level, and processes change over time, so confirm your own schedule and language options with your recruiter.

Stage	What candidates commonly describe	Prep focus
Recruiter conversation	Role, team, level, and logistics	Ask whether the team is consumer-facing, search, data, or platform - it changes what to practice
Technical screen	Live coding in a shared editor, sometimes preceded by an online assessment	Medium-level data structures and algorithms, explained as you go
Final interviews	Several conversations, commonly virtual	Coding, system design for experienced roles, and behavioral questions
Decision	Interviewer debrief and recruiter follow-up	Consistent signal across every round

Coding topics to prioritize

Candidates commonly report standard data structures and algorithms problems, some of them framed around homes, prices, and places. A sensible order of priority:

• Hashing and normalization. Grouping records under a normalized address key, removing duplicates, and multi-key sorting such as price, then listing date.
• Geometry for maps. Bounding boxes, distance between coordinates, and point-in-polygon tests.
• Heaps and top-k. The k nearest homes to a point, or the k best matches by a score.
• Intervals and event histories. Status timelines, days on market, and price changes over time.
• Binary search. Price ranges over sorted data and "first event after a given date" questions.
• Modeling the domain. Keep the property (the physical home), the listing (an offer to sell or rent it), and events (price and status changes) separate - a distinction that makes many follow-up questions easier.

Map search: the geospatial core

Searching for homes is a spatial query with extra constraints. The visible map defines an area - usually a rectangle, sometimes a shape the user draws or a boundary such as a neighborhood or school zone - and the system has to return the matching homes inside it, filtered, sorted, and paged, quickly enough that panning feels smooth.

The mechanics of spatial indexing - geohashes, quadtrees, and other schemes that turn a two-dimensional position into a key you can store and scan - are covered in our mapping system design walkthrough. Listing search layers different problems on top of those mechanics:

• Spatial plus attribute filters. A price range and a map area arrive together; decide which filter to apply first and how an index can serve both.
• Zoom-dependent results. A zoomed-out view can contain far more homes than anyone can read as pins, so systems commonly return clusters or counts per area and switch to individual listings as the view narrows.
• Polygons as well as rectangles. Drawn areas and boundaries need point-in-polygon tests, usually after a cheap bounding-box check has narrowed the candidates.
• Paging over moving data. Listings appear and disappear while someone scrolls, so cursor-based paging on a stable sort key avoids the duplicates and gaps that offset-based paging can produce.
• Distance done properly. A degree of longitude covers less ground farther from the equator, so radius searches need a great-circle formula such as haversine rather than raw differences in degrees.

Here is the flavor of a coding problem in this space: index listings so that a map-view query does not have to scan every home.

import math
from collections import defaultdict

CELL = 0.01  # grid cell size in degrees (about 1.1 km north-south)

class ListingGrid:
    def __init__(self):
        self.cells = defaultdict(list)          # (row, col) -> listings

    def _cell(self, lat, lng):
        return (math.floor(lat / CELL), math.floor(lng / CELL))

    def add(self, listing):
        self.cells[self._cell(listing["lat"], listing["lng"])].append(listing)

    def in_view(self, south, west, north, east, max_price=None):
        r0, c0 = self._cell(south, west)
        r1, c1 = self._cell(north, east)
        found = []
        for r in range(r0, r1 + 1):
            for c in range(c0, c1 + 1):
                for home in self.cells.get((r, c), []):
                    if not (south <= home["lat"] <= north and west <= home["lng"] <= east):
                        continue                # edge cells overlap the view only partly
                    if max_price is not None and home["price"] > max_price:
                        continue
                    found.append(home)
        return found

The strong answer states the cost - proportional to the cells the view touches plus the listings inside them, instead of every listing in the index - and then anticipates the follow-ups. Cell size is a trade-off: small cells mean visiting many buckets when the user zooms out, while large cells mean filtering many out-of-view homes when zoomed in, which is why multi-resolution schemes choose a level from the zoom. Updates matter as much as reads, because prices and statuses change constantly, so keep a map from listing ID to cell for cheap removal. Wide views should return counts per cell rather than every home. And a view that crosses the 180th meridian, where west is greater than east, has to be split into two ranges.

Home values: reasoning about valuation

The Zestimate is one of Zillow's best-known features. Zillow describes it publicly as an estimate of a home's market value rather than an appraisal, drawing on public records, listing data, and information submitted by users, along with home details, location, and market trends. That is the right level for an interview too: you do not need, and should not claim, any knowledge of how Zillow's models work internally.

When valuation comes up - most likely for data, machine learning, or pricing-adjacent roles - clear reasoning matters more than any particular formula. Concepts worth being able to discuss:

• Comparable sales. The intuition behind many valuation approaches: similar homes, nearby, sold recently. Defining "similar", "nearby", and "recently" is where the engineering judgment lives.
• Features and their gaps. Size, bedrooms, bathrooms, lot, age, and location are obvious inputs. Missing, outdated, or wrong home facts - an unrecorded renovation, for example - are the everyday problem.
• Outliers. Some recorded sales do not reflect market value, such as transfers between family members, so data cleaning matters as much as the choice of model.
• Uncertainty. A single number hides how confident an estimate is. A range is more honest, especially where data is sparse, such as rural areas or unusual homes.
• Evaluation. Compare estimates with eventual sale prices, and break error down by region, price tier, and home type rather than trusting one overall figure. A home that is currently listed carries an extra, highly informative signal - its asking price - so it is reasonable to measure listed and unlisted homes separately.
• Fairness. Housing is high-stakes and regulated. Check whether error is systematically worse in some neighborhoods than others, and be ready to explain why that matters.
• Serving. Estimates are needed for many homes while the underlying data changes daily. Discuss batch recomputation versus on-demand updates, and what should happen when a homeowner corrects a home fact.

Listing data from many sources

Search is only as good as its data, and listing data is messy by nature. It arrives from multiple listing services (MLSs) and brokerages, from agents and owners posting directly, from rental managers, and from county public records such as assessments and recorded sales - each with its own format, update schedule, and reliability. Industry standards such as the RESO Data Dictionary aim to make listing fields consistent, but engineers still normalize, match, and reconcile. The design themes that follow:

• Entity resolution. The same home can arrive from several sources with different address formats ("Apt 4B", "Unit 4B", "#4B"). Normalize addresses, use stable identifiers such as parcel numbers where they exist, and decide explicitly what counts as a match.
• Field-level precedence. When sources disagree about bedrooms or square footage, decide which source wins for each field, and keep provenance so the decision can be explained and revised.
• Status freshness. A home still shown as for sale after it has gone pending frustrates buyers and agents alike. Track how far behind each source is, and alert when a feed goes quiet.
• Ordering and duplicates. Updates can arrive late, out of order, or twice. Apply them by source timestamp or sequence number rather than arrival time, and make processing idempotent so replays are safe.
• Deletes nobody sends. Some sources deliver full snapshots rather than change events, so a listing that vanishes from a snapshot has to be inferred as withdrawn - carefully, because a truncated file looks exactly the same.
• Index lag. Changes flow from ingestion into the search index, so define how quickly a price cut or status change must become visible, and what the product shows in the meantime.

Deciding how stale a cached value may be is a close cousin of the price-freshness problem in our Expedia coding interview guide. With listing data, much of the difficulty sits upstream, in reconciling sources before anything reaches a cache.

Consumer product engineering

Zillow is a consumer product used on the web and in mobile apps, so engineering choices show up directly in how it feels. For product-facing teams, it helps to show you think about that:

• Responsive map interactions. Debounce requests while the user pans, cancel requests that are no longer needed, and make sure a slow, older response can never overwrite newer results.
• Saved searches and alerts. Telling someone quickly that a matching home was listed means checking each new listing against a very large number of stored searches - the reverse of ordinary search - and deciding how often to notify without becoming noise.
• Trust in the details. People make large financial decisions with price history, status, and home facts, so correctness and clear labeling matter more than clever features.
• Experimentation. Ranking and interface changes are commonly evaluated with controlled experiments; know how you would pick a metric and avoid reading too much into a noisy result.

For the delivery side of alerts - user preferences, rate limits, retries, and deduplication - our notification system design walkthrough covers the parts that are not specific to real estate.

Representative problem types

These are problem types that fit Zillow's domain, alongside the standard data structures and algorithms problems candidates commonly report. Treat them as categories to practice, not as a list of actual prompts:

• Listings in an area. Return homes inside a bounding box or radius that match filters, efficiently, then extend the solution to a drawn polygon.
• Nearest homes. Find the k closest listings to a point using a heap and a correct distance function.
• Merging listing feeds. Combine records from several sources, deduplicate them, and apply status updates that arrive out of order.
• Price and status history. From a stream of events, compute days on market, the current price, or the largest price drop within a time window.
• Comparable homes. Given a home, select similar recent sales nearby and summarize them - for example, a median price per square foot - while handling missing fields.
• Build and extend a component. A saved-search matcher that starts with price and bedroom filters, then has to support areas drawn on a map.
• Design (experienced roles). Map-based home search, a listing ingestion pipeline with freshness targets, saved-search alerts, or serving home-value estimates at scale.

What interviewers tend to value

• Clarifying the data. Asking what a record looks like, which fields can be missing, and whether duplicates exist before writing code.
• Spatial correctness. Boundaries, distances, and edge cells handled on purpose rather than approximately by accident.
• Freshness judgment. Knowing which data must be current - status, and price at the moment someone acts - and which can lag.
• Honesty about uncertainty. Explaining error and confidence rather than presenting a single number as fact.
• User focus. Connecting technical choices to what a buyer, renter, or agent actually experiences.

On integrity: the point of preparing is to understand these trade-offs well enough to reason about them live. Follow the rules your interviewer sets for each round, and expect follow-up questions that change the constraints - the part that only real understanding survives.

A two-week Zillow prep plan

1. Days 1-3: Hash maps, multi-key sorting, and string normalization, framed as deduplicating listings from several sources.
2. Days 4-5: Geometry for maps - bounding boxes, haversine distance, and point-in-polygon - then implement the grid index above and extend it with removals and per-cell counts.
3. Days 6-7: Heaps for nearest-home queries, then intervals and event histories for status timelines and price changes.
4. Days 8-10: Design practice out loud: map-based home search, a listing ingestion pipeline with freshness targets, and saved-search alerts.
5. Days 11-12: Valuation concepts: comparable sales, outliers, uncertainty ranges, and error broken down by segment. Go deeper if your role is in data science or machine learning.
6. Days 13-14: Behavioral stories mapped to Zillow's published values - including a data-quality problem you found and fixed - and a timed solo mock with one coding problem and one design prompt.

FAQ

What is the Zillow software engineer interview process like?

Candidates commonly describe a recruiter conversation, a technical screen with live coding, and a set of final interviews, commonly virtual, covering coding, system design for experienced roles, and behavioral questions. Some roles reportedly add an online assessment. The number and order of rounds vary by team and level, and processes change over time, so confirm the details with your recruiter.

What kind of coding questions does Zillow ask?

Candidates commonly describe standard data structures and algorithms problems, sometimes framed around real-estate data such as listings, prices, addresses, and locations. Useful areas to practice include hash maps and sorting, heaps for nearest-home and top-k queries, intervals and event histories, and basic geometry such as bounding boxes, distances, and point-in-polygon tests.

Do I need to know how the Zestimate works?

No insider knowledge is expected, and you should not claim any. Zillow publicly describes the Zestimate as an estimate of a home's market value, not an appraisal. What helps is reasoning clearly about valuation concepts: comparable sales, data quality and outliers, uncertainty ranges, and measuring error across regions and home types. Data science and machine learning roles are likely to go deeper.

Does Zillow ask geospatial or map search questions?

It depends on the team, but map-based search is central to the product, so location problems are a natural fit for coding and design discussions. Be ready to filter listings inside a map view, compute distances correctly, test whether a point lies inside a boundary, and explain how a spatial index or grid avoids scanning every home.

What should I study for a Zillow system design interview?

Practice map-based home search with filters and paging, a listing ingestion pipeline that merges many sources and keeps status current, saved-search alerts that match new listings against stored searches, and serving precomputed home-value estimates. In each design, say how fresh the data needs to be and what the user sees when it is not.