Workday · Primly Community

Workday data engineer interview, pipelines and SQL, here's what they covered

de_derek · 4 replies

completed a Workday data engineer loop earlier this year. role was on the internal data platform team (not customer-facing product, the infra that runs their own analytics). sharing what they hit on.

coding / OA: standard HackerRank. one SQL, one python. the python problem was processing a flat list of events and reconstructing a session hierarchy. medium difficulty. time limit was fine.

technical phone screen: 30 minutes, one SQL question and one conceptual. SQL was: given a table of employee status changes (start, end, event type), write a query to find the current headcount per department per day for the last 90 days. it's a date-spine / SCD type problem. i used a calendar table CTE. they didn't ask me to optimize but nodded at the approach.

onsite: 4 rounds.

Pipeline design round: design a data pipeline that ingests HR system events (hires, transfers, terminations) from multiple Workday tenants, deduplicates them, and feeds a real-time analytics dashboard. they cared about: exactly-once semantics vs at-least-once and trade-offs, event ordering across tenants, how you'd handle schema drift as Workday adds fields to their API. kafka + flink type conversation but they weren't attached to specific tech. the concepts mattered.

SQL depth round: advanced. partition-based calculations, incremental aggregation, lag/lead for detecting state changes. one problem was essentially: find employees who changed departments more than twice in a calendar year. the schema had a raw event log, not a clean state table. you had to reconstruct state from events.

data modeling round: dimensional vs normalized, when to use each, how to model slowly changing dimensions for org charts. they explicitly called out that org hierarchies at enterprise scale are messy and asked how i'd handle that. i talked through adjacency lists vs closure tables vs nested sets. that last one got some engagement.

behavioral: standard.

overall: harder SQL than most DE interviews i've done. the pipeline design round was solid and practical. not a lot of weird gotchas, just genuine depth.

4 replies

alex_design

the 'schema drift from a vendor API' question is genuinely interesting and under-discussed. how did you answer the schema drift part? did you go the contract testing route or more ad-hoc detection?

brand_ben

i went: schema registry with compatibility enforcement on write, dead letter queue for anything that fails validation, and an alerting layer that pages the team when new unknown fields appear more than N times in an hour (so you catch additive changes before they silently drop data). they liked the dead letter + alerting combo.

sec_sasha

the closure table vs adjacency list question: i've only ever seen that come up in interviews at companies with genuinely hierarchical data. makes sense for Workday. did they have a preference or were they just probing depth?

ae_andre

finding employees who changed departments more than twice from a raw event log is a solid interview problem actually. you have to reconstruct state, deduplicate, compare transitions. not the kind of thing a junior DE can fake their way through.