What the round is like
You'll usually get 60 to 90 minutes with two engineers. Candidates say the interviewers asked about idempotency, retries, how services talk to each other, monitoring, reliability and scale, so expect the conversation to go past the first diagram.
What people have been asked
These come up in candidates' own write-ups of their interviews. We wrote the example prompts ourselves, so the wording you get will be different.
Search hotel availability
Return the hotels and rooms available for someone's dates, fast, under heavy traffic.
Availability changes constantly and depends on every night in the range, which makes it hard to cache.
How it might be asked
Design a hotel search and availability system. Given a city and a date range, return the hotels with rooms available for every night, and make sure it holds up under high traffic.
Key concepts to know
Try this Interview
Design a reservation system
Guests book rooms and hotel staff manage rooms, prices and bookings.
The prompt is just "users and admins", so you set the scope. Expect a follow-up on two guests grabbing the last room at the same moment.
How it might be asked
Design a hotel reservation system with users and admins. Users book rooms for a date range, and admins manage rooms, prices and see their bookings.
Key concepts to know
Try this Interview
Detect fraudulent credit cards
Block bookings made with cards that have been reported as fraudulent, for book now, pay later stays.
The bad-card list shows up after the booking's made, so you have to match new reports against bookings that already exist, before the charge goes through.
How it might be asked
Guests can book now and pay later, on or before check-in. A third-party API gives us newly reported fraudulent cards. Design a service that finds and blocks bookings made with those cards.
Key concepts to know
Try this Interview
Charge cards on a schedule
An internal system that takes payment in parts, like half now and half before the stay.
Each charge has to happen once, for the right amount, at the right time, even when the payment provider times out or a job crashes halfway.
How it might be asked
Design an internal system that captures money from a guest's card based on a per-booking setting, for example 50% at booking and 50% two days before check-in. It has to charge the right amount at the right time, even when things fail.
Key concepts to know
Try this Interview
What's really being tested
| Topic | What you're being asked, basically |
|---|---|
| Double-booking | How do you make sure only one person gets the last room? |
| Retries | What happens when a payment request is sent twice? |
| Timing | How do you make sure a scheduled charge runs once, on time? |
| Monitoring | How do you know the system's actually working? |
How to work through a question
- Figure out what you're building. Who's using it, what does it need to do, and what can you ignore?
- Do some rough math. How many requests, how much data, more reads or more writes? Those answers decide a lot.
- Walk through one request. Draw the simplest thing that works before you add anything fancy.
- Pick storage last. Once you know what gets read, how often and how fresh it has to be, the choice gets a lot easier.
- Then try to break it. What happens in a traffic spike? What if a server dies?
Key concepts to know
If you're rusty on any of these, start here.
- Caching strategiesMake reads faster, and figure out what to do when data changes.
- Consistency and the CAP theoremWhat happens when copies of your data can't agree.
- Idempotency and retriesMake sure a retried request doesn't happen twice.
- Relational vs non-relational databasesPick a database based on how you'll actually use it.
- Sharding and consistent hashingSplit data across machines and keep it balanced.
- Message queues and event streamsKeep services from depending on each other, and handle traffic spikes.
- Search and inverted indexesFind text fast, rank what comes back, and keep the index fresh.
Sources
We pulled this together from candidates' own write-ups of their interviews. They don't always agree, and things change over time.
- Roundz: Booking.com SDE-2 Amsterdam (Jul 2025)
- Jointaro: SWE II Amsterdam (Jul 2024)
- Jointaro: SWE Amsterdam (Jun 2024)
- Jointaro: Software Developer Bengaluru (Feb 2024)
- Jointaro: SWE US (Feb 2025)
- Jointaro: SWE UK (Dec 2024)
- Jointaro: SWE Netherlands (Jul 2025)
- LeetCode Discuss: Award Top K Hotels (Booking OA)
Practice Loop is an independent practice tool and isn't affiliated with or endorsed by Booking.com.