Did a system design round for a senior software engineer role at Boeing earlier this year. This is the part where I can save you some prep time.
It is not a distributed systems design interview in the classic sense. You won't be asked to design Twitter at scale or build a globally consistent key-value store. The bar is different.
What they actually asked me: design a system for tracking and scheduling preventive maintenance across a fleet of aircraft. The scope was: ingest maintenance records from multiple data sources (some legacy SOAP services, some modern REST), expose a dashboard, alert mechanics when a maintenance window is approaching, and handle the case where a plane gets pulled from service early.
That sounds complex but the conversation was really about: can you decompose the problem, identify the data model, talk about reliability at the right level of depth. They were looking for whether I understood queuing (they liked that I mentioned a message broker for async alerts), how I thought about data consistency across legacy + modern sources, and whether I said the word 'monitoring' unprompted. I did. They liked that.
Big differences vs. FAANG system design: No scale math. Nobody asked me to estimate QPS for a fleet of 500 planes. The scale is moderate and they know it. Compliance and auditability came up. FAA record-keeping is a real constraint. They want engineers who think about that. Deployment environment matters. Some Boeing systems run on-premise or in air-gapped environments. Cloud-native-only answers sometimes miss the point.
I prepped with the standard system design material and it was honestly overshoot. I'd focus on: solid fundamentals, REST + message queues, data modeling, and understanding why correctness matters more than throughput here.
Total design round was 50 minutes, with about 10 minutes of behavioral at the end.