Went through the Splunk senior SWE loop earlier this year, targeting an L5 equivalent role on their observability platform team. Sharing the system design round specifically because I couldn't find much specific to Splunk when I was prepping.
The round was 60 minutes. The interviewer gave me a prompt roughly around designing a log aggregation and search pipeline at scale. Makes sense given what Splunk actually does, so if you're interviewing there, think through that domain. Not a surprise.
What they cared about in roughly the order they probed:
Ingestion path first. How do you handle variable-rate log producers? burst buffering, backpressure, at-least-once vs. exactly-once delivery. I talked Kafka-style queuing and they pushed on partition strategy and consumer lag handling.
Indexing and search latency. This is where it got specific to their world. They wanted to know how you'd structure an inverted index for log text search and what tradeoffs you'd make between index write speed and query latency. Think time-bucketed indices, compression, bloom filters. If you've read anything about how Elasticsearch works under the hood, it maps pretty directly.
Storage tiering. Hot/warm/cold data movement. They wanted concrete numbers on when you'd tier and what the access pattern difference is.
Multi-tenancy. This surprised me a little. How do you isolate data per tenant in a shared infra while keeping cost predictable? It was more of a "have you thought about this" check than a deep dive.
The pace was collaborative. The interviewer wasn't trying to trip me up, more tracking how I handled ambiguity and whether I'd drive the design myself or wait for prompts. I had to ask clarifying questions at the start about scale and consistency requirements or they wouldn't offer them unprompted.
One thing: don't walk in with a generic distributed systems design. Anchor it to log pipelines, event streams, time-series data. They'll know if you're drawing a generic boxes-and-arrows diagram.