Booking.com Coding Interview Questions: Experimentation, Metrics, and Scale

Booking.com is part of Booking Holdings, alongside sister brands such as Priceline, Agoda, and KAYAK, but it has an engineering identity of its own. It is best known inside the industry for its experimentation culture: product changes are commonly shipped as A/B tests, and the data - not the most senior voice in the room - is expected to decide what stays. If you prepare for Booking.com like any other large consumer company, you will cover the algorithms and miss the mindset interviewers are often listening for.

This guide covers the loop candidates commonly describe, how experimentation and metrics thinking show up in it, what Amsterdam-centred international hiring means for you, 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 Booking.com engineering loop

Candidates typically describe a process shaped roughly like the table below. The number of rounds, their order, and whether they are virtual or on-site vary by team, level, and hiring cycle, and processes change, so confirm your specific schedule with your recruiter.

Some candidates describe being hired into the company first and matched to a team later, while others interview for a specific team. Ask which applies to you, because it changes whether you should prepare broad fundamentals or a particular product area.

The experimentation culture, and why it reaches the interview

Booking.com has written and spoken publicly about running experiments at large scale and letting results guide product decisions. You do not need to be a data scientist to interview there, but a few ideas are worth being fluent in, because they shape how engineers work day to day:

• Assignment. Each user should land in the same variant every time they return, usually by hashing a stable identifier, so the experience is consistent and the data is clean.
• Primary and guardrail metrics. A test has a metric it is trying to move and metrics it must not harm, such as page speed, errors, or cancellations.
• Enough traffic before trusting a result. Small samples and early peeking produce false wins; decide the sample size and duration up front.
• Small, reversible changes. Feature flags let a team ship behind a switch, test on a slice of traffic, and turn a change off quickly if a guardrail moves.

Topic emphasis for the coding rounds

Coding rounds are commonly described as standard data structures and algorithms with a strong emphasis on clean, maintainable code. Prioritize roughly in this order:

• Hash maps and sets. Counting events, grouping users by variant, and joining records by key.
• Sorting and custom comparators. Ordering results by several criteria and handling ties predictably.
• Sliding windows. Rolling counts and rates over time, such as errors in the last few minutes - the sliding window pattern is worth making automatic.
• Heaps. Top-k items by a metric, and streaming "most frequent" questions.
• Trees and graphs. Traversal fundamentals, which appear across many companies' loops.
• Readable code and tests. Clear names, small functions, and a quick check of the edge cases you mention.

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 traffic, measurement, and safe change.

An experimentation and feature-flag platform

How do thousands of product changes get tested without slowing pages down? Discuss deterministic assignment at request time, storing experiment configuration so it can change without a deploy, logging which variant each user saw, and preventing overlapping experiments from contaminating each other. Cover the kill switch: how quickly a bad variant can be turned off everywhere.

Event collection and metrics aggregation

Experiments are only as good as their data. Expect to reason about collecting page-view, click, and booking events at very high volume, deduplicating them, joining them to variant assignments, and producing trustworthy aggregates. Talk about late-arriving events, idempotent processing, and the difference between real-time dashboards and the slower, validated numbers used to call a result.

High-traffic read paths

Search results and property pages are read far more often than they change, which makes caching, pre-computation, and graceful degradation central. Be ready to explain what is cached, how it is invalidated when availability or price changes, and what still works if a downstream service is slow. Our system design reference is a quick refresher on the building blocks.

Ranking and personalization

Which properties appear first for a given traveler is both a ranking problem and, at Booking.com, an experimentation problem: every ranking change is something you would want to test. For the modeling and serving side, our recommendation system design walkthrough covers the fundamentals; in the interview, spend your time on how you would measure a ranking change fairly.

Amsterdam-centred, internationally hired

Booking.com is headquartered in Amsterdam, and a large part of its engineering organisation is based there. It hires engineers from many countries, and English is widely used as the working language in its technology teams. In practice that means a few things worth clarifying early:

• Location and relocation. Ask whether the role is based in Amsterdam, another office, or allows remote work, and what relocation support applies. This varies by role and over time.
• Time zones. Interviews may be scheduled around Central European Time; agree on a slot where you will be sharp.
• Communication across cultures. Teams mix many nationalities, so clear, direct explanation of your reasoning is valuable in every 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:

• Event counting and aggregation. Summarize a log of events by user, variant, or time bucket.
• Rolling-window metrics. Compute rates or detect spikes over a moving time window.
• Top-k and frequency. Find the most viewed or most booked items from a large stream.
• Sorting with rules. Order search results by several criteria with clear tie-breaking.
• Build and extend a component. Implement a small feature-flag or rate-limiting class, then handle new requirements.
• Experimentation-flavored design (experienced roles). Assignment and flag services, event pipelines, metrics aggregation, or high-traffic page serving.

Here is the flavor of the experimentation theme in code: deterministically assigning users to variants, then computing a conversion rate per variant from an event log.

import hashlib
from collections import defaultdict

def assign_variant(user_id, experiment, variants=("control", "treatment")):
    key = f"{experiment}:{user_id}".encode()
    bucket = int(hashlib.sha256(key).hexdigest(), 16) % 100
    return variants[bucket * len(variants) // 100]

def conversion_by_variant(events, experiment):
    # events: iterable of (user_id, event_type)
    visitors, converters = defaultdict(set), defaultdict(set)
    for user_id, event_type in events:
        variant = assign_variant(user_id, experiment)
        visitors[variant].add(user_id)
        if event_type == "booking":
            converters[variant].add(user_id)
    return {v: len(converters[v]) / len(visitors[v]) for v in visitors}

The strong answer explains why the hash includes the experiment name (so the same user is not always in "treatment" across every test), counts unique users rather than raw events, and states the complexity - one pass, O(n) time. It then raises the follow-ups an interviewer is likely to explore: uneven traffic splits, users who book without a recorded visit, and why a difference in these two numbers is not yet a result without enough sample size.

What interviewers actually score

• Readable, correct code. Clear structure and edge cases handled, not just a passing answer.
• Measurement instinct. Knowing how you would tell whether a change worked.
• Performance awareness. Respecting latency on pages that serve enormous numbers of requests.
• Humility with data. Behavioral stories where evidence changed your mind, or an idea you believed in did not win.
• Clear communication. Explaining trade-offs plainly to colleagues from many backgrounds.

A note on integrity: prepare thoroughly and reason honestly in the room. A company that values evidence tends to probe the reasoning behind your answers, and real understanding holds up where a memorized script does not.

A realistic two-week prep plan

1. Days 1-3: Fundamentals - hash maps, sets, and sorting with comparators. Write readable solutions and test the edge cases.
2. Days 4-6: Sliding windows and heaps framed as metrics problems: rolling error rates, top-k viewed properties.
3. Days 7-8: Trees and graphs, then build a small feature-flag class and extend it with a percentage rollout.
4. Days 9-11: Design. Practice an experimentation platform, an event and metrics pipeline, and a high-traffic property page, naming a primary and guardrail metric each time.
5. Days 12-13: Behavioral stories about data-driven decisions, a failed experiment or idea, and working in an international team. Settle your location and relocation questions with your recruiter.
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 Booking.com coding interview like?

Candidates commonly describe a recruiter conversation, a technical screen or online assessment, and a set of final rounds covering coding, system design for experienced roles, and behavioral questions. Coding problems are usually standard data structures and algorithms with an emphasis on clean, readable code and clear reasoning. Formats vary by team, level, and hiring cycle, and processes change, so confirm the details with your recruiter.

Why does experimentation matter in a Booking.com interview?

Booking.com is widely known for a culture of running many A/B tests and using the results to decide which product changes ship. Engineers are not expected to be statisticians, but it helps to understand how users are assigned to variants, what a primary metric and a guardrail metric are, why tests need enough traffic before you trust a result, and how to design features that can be switched on and off safely.

Does Booking.com ask system design questions?

For mid-level and senior engineers, candidates typically report a design round. Natural themes include serving search and property pages under very high traffic, building an experimentation or feature-flag platform, collecting and aggregating event data for metrics, and keeping availability and prices consistent across a large inventory. Expectations vary by team and level.

Do I need to relocate to Amsterdam to work at Booking.com?

Booking.com is headquartered in Amsterdam and much of its engineering organisation is based there, and it hires engineers from many countries. Whether a specific role requires relocation, what support is offered, and whether other offices or remote arrangements apply depends on the role and changes over time, so ask your recruiter early in the process.

What topics should I study for a Booking.com software engineer interview?

Cover hash maps, sorting, sliding windows, heaps, and basic graph and tree traversal, and practice writing readable, well-tested code. For design, practice high-traffic read paths, caching, event pipelines, and feature flags. Add a working understanding of A/B testing concepts, and behavioral stories about using data to make a decision and changing your mind when the evidence disagreed with you.