Design a Domain Model

Workday leads its design conversation with a round that most generic system-design prep skips entirely. You are handed a domain, often a compact everyday one, and asked to model it as a clean set of classes drawn out as a UML class diagram. There is no traffic to size and no cache tier to place. None of it is about load. The whole conversation is about the objects: what the entities are, what each one is responsible for, how they relate, and how many of each sits on either end of a relationship. Objects first, always. This is the most consistently reported technical round in the loop, and it reaches interns and junior application engineers as readily as it reaches seniors. Rehearse it hardest.

The round has a shape that barely changes across reports. You draw a first model, and then the interviewer moves the brief. A new entity, a new rule, or a fresh query arrives partway through, and the real grading begins. Does your model absorb the change as a small edit, or does it have to be torn up? Then a pointed question lands, something like how many debit cards are linked to a particular customer, and you answer it by traversing your own diagram. If the associations were honest, the answer is a clean walk. If they were vague, the query exposes it. Almost everything the round scores lives in those two moments, the change and the query. The tidiness of the first drawing counts for little. The first drawing is table stakes.

The Workday angle

Workday sells systems of record for people, pay, and money, so the design question is "model the business." Surviving a traffic spike matters less. The products are all entities and the relationships between them. A worker belongs to an organization, an account issues cards, a document carries versions. An object-oriented design round probes exactly that. The prompt that carries weight goes: here is a domain, give me the classes, the responsibilities, and how they relate. Now handle the requirement I'm adding.