Went through the Expedia SWE L5 loop in early 2026. System design was two rounds, 45 minutes each, and they're pretty focused on travel-domain problems. Not generic "design Twitter" stuff. My prompts were something like: design a hotel search ranking service and design a notifications system for flight status updates.
What they actually cared about:
Availability vs. consistency tradeoffs. Expedia's core product is a booking platform so they drill hard on what happens when inventory systems are partially unavailable. Be ready to talk CAP theorem in a concrete way, not just recite the acronym.
Scale at booking spikes. Think Black Friday for flights. Horizontal scaling, caching layers (Redis), queue-based processing. If you mention Kafka, know why you'd use it vs. SQS and be specific about partition keying.
APIs and downstream dependencies. Their backend talks to hundreds of supplier APIs (airlines, hotel chains). They want to see that you've thought about circuit breakers, retry logic with backoff, and graceful degradation when a supplier is down.
The interviewers were senior ICs. One was clearly in the travel supply team. They pushed back when I made assumptions and wanted me to quantify things: "How many booking events per second? What's your SLA target?" That kind of rigor.
Leveling: L5 at Expedia is roughly equivalent to senior at most mid-tier companies. The design bar is real but not Meta/Google impossible. I'd put it at: you need to show you can scope ambiguous problems and make explicit tradeoffs, not just whiteboard a CRUD app.
Recommend doing at least one mock on a distributed booking or reservation system before your loop. The travel context comes up a lot and it's easy to fumble if you've only practiced abstract examples.
Happy to answer specifics in the comments.