Just finished the L5 loop at eBay (San Jose, applied to a backend platform team). Going to document the system design round because it was different from what I prepared for.
The round was 60 minutes. They gave me a prompt that was basically: design a notification service that handles order status updates for buyers and sellers at eBay's scale. Classic, but the interviewer went deep pretty quickly.
What they actually wanted to see:
Scope clarification first. I jumped straight to the diagram and had to backtrack. They want you to ask: what volume of events per second? what delivery guarantees? push or pull on the client side? SMS/email/push or all three? Spend 5-6 minutes here.
Message queue design. They pushed hard on Kafka vs. SQS tradeoffs. Not just "I'd use Kafka" but: partition key strategy, at-least-once vs exactly-once semantics, consumer group design for fan-out. Know this cold.
Database choice. I went with DynamoDB for notification state. Interviewer asked me to walk through the access patterns and whether I'd need a GSI. She was comfortable with Cassandra too, but wanted justification, not just name-dropping.
Failure modes. What happens if the notification worker crashes mid-send? How do you avoid double-notifying? They spent 15 minutes just on this.
No concurrency puzzles, no LeetCode-style coding in this round. Pure systems.
For level calibration: L5 at eBay is roughly senior eng. The expectation is you drive the design, you don't wait for hints, and you surface the hard tradeoffs yourself. If the interviewer is constantly nudging you forward, that's probably a no-hire signal.
Prep I'd recommend: Design a rate limiter, design a notification fanout system, and really nail consistent hashing and database sharding. The eBay infra has a lot of legacy so they appreciate candidates who understand why you'd evolve from a monolith vs. greenfielding a microservice.