Just cleared the onsite for a senior SWE role in their technology group. The system design round was the most interesting part so writing it up.
The prompt: design a real-time transaction monitoring system. Detect anomalies in payment flows at scale, store audit trails, surface alerts to analysts.
That's a pretty good system design question actually. It forces you to think about: high-write throughput (they explicitly said "millions of transactions per day") latency requirements for fraud detection (sub-second vs. batch) storage tradeoffs between hot/warm/cold tiers how you'd make the audit trail tamper-evident
I started with requirements clarification, which they seemed to appreciate. The interviewer asked a lot of follow-up questions rather than just listening, which I like. They pushed me on what happens when the anomaly detection service goes down, how I'd handle backpressure, whether I'd choose Kafka vs. a simpler queue for this scale.
I drew out a pretty standard event-driven architecture: producers -> Kafka -> consumers with detection logic -> alerts -> PostgreSQL for durable storage with a read replica for the analyst dashboard. They seemed satisfied but pushed on whether Postgres would hold up at the stated write volume. Good catch, I pivoted to a time-series DB option and discussed tradeoffs.
For prep: the usual Grokking / Designing Data-Intensive Applications material is the right foundation. But BNY questions tend to have a financial services flavor: idempotency matters, audit trails matter, regulatory compliance surfaces as a constraint. Worth thinking about those angles before your round.
The interviewer was a principal engineer who'd been there 8 years. Thoughtful questions, not gotcha stuff. The round felt collaborative.
One thing: they use a whiteboard tool that isn't Excalidraw or Miro, it's something internal. Works fine but bring a simple drawing style, don't plan on fancy diagrams.