Just finished this loop and wanted to write up the system design piece specifically because I couldn't find anything useful when I was searching.
The system design round was 60 minutes with two interviewers, one from the platform team and one seemed to be a tech lead from digital commerce. The problem they gave me: design a product recommendation engine for their e-commerce platform, factoring in real-time browsing data and inventory constraints.
A few things that stood out.
It's not a trick. They weren't trying to catch me on CAP theorem trivia or obscure sharding strategies. They wanted to see how I reasoned through scope, who I'd design for (hundreds of millions of product page views globally, multiple brands), and how I'd handle latency vs. freshness tradeoffs for recommendations.
They asked about failure modes. What happens if the recommendation service is down? How does the frontend degrade gracefully? This felt very intentional, like the team has actually dealt with this problem.
They pushed on data pipelines. I mentioned streaming with Kafka and they asked good follow-up questions about partitioning strategy and consumer lag. Nothing impossible, but not surface-level either.
The behavioral framing was woven in. About 20 minutes in one of them asked, 'have you actually built something like this?' and the conversation shifted to a real past project for a bit. It wasn't a separate behavioral section, just embedded.
For prep: I used the classic system design resources (Designing Data-Intensive Applications, a few mock sessions). The ELC-specific context that helped: they have 25+ brands running on shared infrastructure globally. Think about multi-tenancy, CDN strategy for assets, and how inventory signals from physical retail affect online recommendations.
The level being assessed felt like a senior/staff IC who can lead design decisions, not just describe them. If you're targeting a staff-level role here, bring a real past project where you made consequential architectural calls.