Went through the BMS system design round for a Senior Software Engineer (roughly L5 equivalent) position on their data platform team. This is a company where "senior" means a lot of cross-team coordination, so the design round reflected that.
The prompt was something like: design a data ingestion and processing pipeline for clinical trial data that needs to land in multiple downstream systems (analytics, regulatory reporting, a patient portal). They specifically called out compliance and data privacy as constraints upfront.
What they actually cared about: Compliance-aware design. They pushed hard on where PII lives, how you handle audit logging, and how you'd enforce data residency rules across regions. HIPAA came up explicitly. If you've never thought about regulated data systems, study up. Reliability over cleverness. When I proposed a fancy event-driven architecture with exactly-once semantics via Kafka, the interviewer was more interested in how we'd handle a 6-hour outage during a critical trial window. Operational simplicity scored points. Cross-functional clarity. They asked how I'd communicate the tradeoffs to a regulatory affairs team that has no engineering background. This is very BMS.
What I wish I'd done differently: I spent too long on the happy path and not enough on failure modes. They were clearly evaluating judgment about what breaks in regulated environments, not just architectural breadth.
Format: 45 minutes, collaborative Google Doc plus whiteboarding on Teams. Interviewer shared a doc with the prompt beforehand. Felt more like a working session than a gotcha.
If you're interviewing for infra or platform at BMS specifically, brush up on: data residency, audit logging patterns, idempotent pipelines, and how to explain technical decisions to non-engineers. This is not a "design Twitter" company.