Just finished my Workday onsite for a senior SWE role (what they map roughly to L5 at other companies). Sharing the system design round specifically because I couldn't find much detail anywhere before going in.
The prompt was essentially: design a payroll processing system that handles 100k employees, runs nightly batch jobs, and surfaces errors to HR admins in near real-time. Classic Workday domain, no surprise. They are an HCM / ERP company so expect anything touching workforce data, benefits, or financial reporting to come up.
What the interviewers cared about: Data modeling first. Before I even touched anything about services, they asked me to walk through the core entities. Employee, pay period, earning code, deduction. They actually knew this domain cold and would push back if my schema didn't account for things like mid-period terminations or retroactive pay adjustments. Reliability over throughput. I kept talking about throughput optimizations and they kept redirecting to durability: what happens if the batch job partially fails, how do you avoid double-paying someone, idempotency keys in the payments API. Operations and observability. They explicitly asked how an HR admin would know something failed and how they'd kick off a rerun. A basic monitoring answer didn't cut it. They wanted a specific error queue, a UI that surfaces affected employee records, retry logic.
I don't think you need to know their exact tech stack (they use a mix of their own cloud platform, AWS, and some legacy on-prem depending on customer tier). What you need is solid distributed systems fundamentals with genuine comfort around financial integrity and idempotency.
Two rounds of system design at senior. One was the above, the second was more like a scenario: you've designed this system, now a customer reports discrepancies in Q4 payroll. Walk me through how you'd debug it. More operational / incident-response flavor.
Total onsite was 5 rounds. Came in-person to Pleasanton. Round breakdown in the onsite thread if that's useful.