Expedia Coding Interview Questions: Search, Pricing, and Stale Data

When people say "Expedia", they often mean the website. When you interview, you are usually talking to Expedia Group - the parent company behind a portfolio of travel brands that includes Expedia, Hotels.com, and Vrbo. That distinction matters for your preparation. Many engineering teams do not build one consumer app; they build search, pricing, booking, and platform services that several brands depend on, fed by suppliers such as hotels, airlines, and property owners whose data changes all the time.

This guide covers the loop candidates commonly describe, the travel-search thinking that runs through it, the types of problems worth preparing, and a two-week plan. As with all our company guides, we describe representative patterns rather than publishing invented "leaked" questions, because question sets rotate and pattern fluency is what transfers.

The Expedia Group engineering loop

Candidates typically describe a process shaped roughly like the table below. The number of rounds, their order, and the tools vary by team, level, and location, and processes change, so confirm your specific schedule with your recruiter.

Stage	What happens	Focus
Recruiter call	Role, brand or platform area, level, and format confirmation	Background and motivation
Technical screen	A live coding problem, sometimes preceded by an online assessment	DS&A, communication
Final interviews	Several virtual rounds	Coding, design (level-dependent), behavioral
Decision	Interviewers debrief, recruiter follows up	Signal across all rounds

Ask your recruiter which part of the business the role supports - a specific brand, lodging or flights, payments, or a shared platform - which languages the team uses, and whether you can code interview problems in the language you know best. The answers change how you should practice.

Why travel search shapes the whole loop

Travel search is harder than it looks. A customer types a destination and dates, and behind that request the system has to find matching properties or flights, check whether they are available for those exact dates, fetch a current price, and rank the results in a way that is useful - all fast enough that nobody abandons the page. Three tensions come up again and again:

• Inventory size versus speed. There are far more hotels, rooms, fares, and combinations than you can evaluate fully on every request, so you filter, pre-compute, and rank in stages.
• Freshness versus cost. Prices and availability change constantly and often live with external suppliers. Asking the source every time is slow and expensive; caching is fast but can be wrong.
• Relevance versus fairness to the customer. A ranking has to balance price, location, reviews, and fit with the query, and the price shown should match the price at checkout.

Naming these trade-offs explicitly, and saying which one you would favor for a given step, is what makes a candidate sound like they understand the domain.

Topic emphasis for the coding rounds

Coding rounds are commonly described as standard data structures and algorithms, sometimes dressed in travel data. Prioritize roughly in this order:

• Hash maps and sorting. Grouping results by property, deduplicating the same hotel offered through different sources, and ordering by several keys.
• Heaps and top-k selection. Picking the best or cheapest options from large result sets - review the heap and priority queue pattern until k-way merges feel routine.
• Intervals. Check-in and check-out dates, overlapping reservations, and blackout periods.
• Binary search. Searching sorted prices or timestamps, and "find the first date that satisfies a condition" questions.
• Graphs. Multi-leg routes and connections, where BFS or shortest-path reasoning applies.
• Clean object modeling. Itineraries, rooms, rates, and bookings expressed as clear types you can extend.

Domain themes for design rounds

For mid-level and senior roles, design discussions commonly draw from this problem space. You do not need insider knowledge - you need to reason clearly about scale, freshness, and failure.

Search and ranking across huge inventories

Think in stages: retrieve candidates that match destination and dates, filter by hard constraints such as availability and guest count, then rank the survivors with a scoring function. Discuss what can be pre-computed offline, what must be computed per request, and how you would measure whether a ranking change helped.

Prices and availability that change constantly

A hotel room or airfare can sell out or reprice between the search page and the booking page. Good answers separate the steps: tolerate some staleness when listing many results, re-check price and availability before confirming a booking, and design a clear customer experience for "the price has changed". Mention rate limits and timeouts when calling external suppliers, and what you show when a supplier is slow.

Caching and consistency trade-offs

Caching is central to fast travel search, and the interesting part is not the cache itself but the policy: how long a price can be trusted, what triggers invalidation, and how different a cached value is allowed to be for search versus checkout. For the mechanics of eviction, replication, and hot keys, use our distributed cache design walkthrough as background and spend your interview time on the freshness policy.

Platform consolidation across brands

Expedia Group has spoken publicly about moving its brands toward shared technology platforms. That makes multi-tenant design a natural theme: one search or booking service that several brands call, with brand-specific configuration, separate traffic patterns, and careful migration so one brand's change does not break another. Talk about API contracts, feature flags, gradual rollouts, and how you would migrate traffic safely. Our system design reference is a quick way to refresh queues, storage, and consistency models before the round.

Representative problem types

These are the kinds of problems candidates commonly describe, given as categories so you prepare the pattern rather than one prompt:

• Merging and ranking results. Combine sorted result lists from several sources and return the top options by price or score.
• Date-range reasoning. Detect overlapping bookings, find available nights, or merge blocked periods.
• Deduplication and grouping. Collapse the same property or fare appearing more than once, keeping the best offer.
• Route and connection search. Find itineraries between two cities within a number of stops or a time budget.
• Build and extend a component. Implement a small class such as a price cache with expiry or a booking tracker, then handle new requirements.
• Travel design (experienced roles). Hotel or flight search, price freshness and caching, supplier integration, or a shared multi-brand service.

Here is the flavor of the merging-and-ranking type: several suppliers each return offers already sorted by price, and you need the k cheapest overall without sorting everything together.

import heapq

def k_cheapest(supplier_results, k):
    # supplier_results: list of lists, each sorted by price
    # each offer is a tuple (price, offer_id)
    heap = []
    for s, offers in enumerate(supplier_results):
        if offers:
            heapq.heappush(heap, (offers[0][0], s, 0))

    best = []
    while heap and len(best) < k:
        price, s, i = heapq.heappop(heap)
        best.append(supplier_results[s][i])
        if i + 1 < len(supplier_results[s]):
            heapq.heappush(heap, (supplier_results[s][i + 1][0], s, i + 1))
    return best

The strong answer states the cost - O(k log m) for m suppliers, versus sorting every offer - and covers edge cases such as empty supplier lists, fewer than k offers in total, and ties on price. It then offers follow-ups an interviewer is likely to raise: deduplicating the same room offered by two suppliers, ranking by a score rather than price alone, and what to do when one supplier times out.

What interviewers actually score

• Clarifying first. Pin down inputs, sort order, ties, and constraints before coding.
• Complexity awareness. Large inventories reward knowing why a heap or pre-sorted merge beats a full sort.
• Freshness judgment. Choosing how stale data can be at each step and explaining the customer impact.
• Designing for failure. Timeouts, partial results, and slow external suppliers handled on purpose.
• Collaboration. Behavioral stories about working across teams on shared systems and migrations.

A note on integrity: prepare thoroughly and reason honestly in the room. Design rounds in particular turn on follow-up questions, and real understanding of your trade-offs holds up where a memorized answer does not.

A realistic two-week prep plan

1. Days 1-3: Fundamentals - hash maps, sorting on multiple keys, and deduplication. Test the edge cases out loud.
2. Days 4-6: Heaps, top-k, and k-way merges, framed as ranking offers from several sources.
3. Days 7-8: Intervals and binary search on date ranges, then graph traversal for multi-leg routes.
4. Days 9-11: Design. Practice hotel search, price freshness and caching, and a shared multi-brand service, naming the customer impact of every staleness choice.
5. Days 12-13: Behavioral stories about ownership, cross-team work, and a migration or rollout that did not go to plan.
6. Day 14: A timed solo mock in your real setup, one coding problem and one design prompt back to back.

FAQ

What is the Expedia Group coding interview like?

Candidates commonly describe a recruiter conversation, one or more technical screens, and a set of final virtual rounds covering coding, design for experienced roles, and behavioral questions. Coding problems are usually standard data structures and algorithms, often easy-to-medium or medium, sometimes framed around travel data such as itineraries, dates, and prices. Formats differ by team, level, and location, and processes change, so confirm the details with your recruiter.

Is Expedia the same company as Expedia Group?

Expedia Group is the parent company, and Expedia is one of the travel brands in its portfolio alongside brands such as Hotels.com and Vrbo. Engineering roles are typically hired by Expedia Group and may support one brand, several brands, or shared platform services used across the portfolio, so ask your recruiter which area the role sits in.

Does Expedia ask system design questions?

For mid-level and senior engineers, candidates typically report a design round. Travel-flavored themes are natural fits: searching and ranking large inventories of hotels and flights, handling prices and availability that change constantly, deciding how stale a cached price can be before it hurts customers, and building shared services that several brands can use. Expectations vary by team and level.

What topics should I study for an Expedia software engineer interview?

Cover hash maps, sorting, heaps and top-k selection, intervals for date ranges, binary search, and graph basics for multi-leg routes. For design, practice search and ranking pipelines, caching and invalidation, rate-limited calls to external suppliers, and consistency trade-offs. Add behavioral stories about ownership, collaboration across teams, and working on large shared systems.

Why do stale prices matter in Expedia design interviews?

Travel prices and availability can change between the moment a search result is shown and the moment a customer tries to book. Caching makes search fast and reduces load on suppliers, but a cached price can be wrong by checkout. Strong answers explain how fresh each step needs to be, for example tolerating some staleness on the results page while re-checking price and availability before a booking is confirmed, and what the customer sees when the price has changed.