Did EY's system design interview last month for a senior software engineer role in their technology consulting practice. Came out of a product company background so wanted to share how it compares.
Short version: the system design portion exists but it is lighter than what you'd see at a true L5/senior loop at a FAANG or growth-stage tech company.
What I was asked: design a real-time dashboard for aggregating data from multiple client systems. The interviewer was interested in the overall architecture rather than deep trade-offs on specific components. He asked about data ingestion, how I'd handle latency requirements, and what databases I'd consider. We talked briefly about caching strategies. At no point did he ask me to size throughput numbers or work through failure scenarios in detail.
I think this makes sense given EY's context. The systems they build are often for clients, not internal infrastructure at massive scale. They want to know you can design something coherent and communicate it to stakeholders who are not engineers. The client communication angle came up explicitly: "how would you explain this to a client's CTO who isn't deep in the tech?"
A few things worth knowing going in. First, they seem to value breadth more than depth. Being able to sketch the full stack and talk about trade-offs at a high level is more useful than going fifteen minutes deep on consistent hashing. Second, cloud fluency matters more than it did two or three years ago. Most of the design conversations I had touched on Azure specifically (EY has a heavy Microsoft relationship). Third, the behavioral framing is woven into the technical rounds in a way that wouldn't happen at a pure tech company. They might ask mid-design how you'd handle a client who disagreed with your architectural choice.
If you're coming from a product company background: dial the technical intensity down one notch but sharpen the communication and consulting framing. That combination is what they're actually hiring for.