Did the system design round at BCG about six weeks ago for a staff-adjacent role. Wanted to write this up because it's different from every FAANG system design I've done.
At Google or Meta, system design is pretty abstract. Design a URL shortener. Design a feed ranking system. The interviewer has a canonical answer in mind.
At BCG, the framing was business-embedded. Mine was something like: "Our consultants need to access structured data from multiple client engagements simultaneously. Design a system for that." The problem had vague requirements, which was intentional. They wanted to see if I would ask clarifying questions before architecting anything.
What they actually evaluated: Did you scope the problem before drawing boxes How do you handle multi-tenancy and data isolation (huge for consulting, clients can't see each other's data) API design clarity (REST vs. event-driven tradeoffs) How do you think about reliability when consultants on a client site have spotty WiFi
I spent maybe 15 minutes just on clarifying questions and requirements gathering. They seemed pleased with that. When I jumped too fast into DB schema choices, the interviewer pulled me back with "what are we optimizing for?"
The interviewer was a principal engineer, not a manager, very technically sharp. No whiteboard tricks. They wanted real engineering thinking applied to their actual problem domain.
One thing that surprised me: they explicitly asked about data compliance at the end. GDPR, data residency, client confidentiality. Not deep security architecture, but you should have an opinion.
Prep advice: practice with business-context prompts, not just abstract system design. Think about the domain before you diagram. And know your CAP theorem cold because it came up.