Schedule Employee Field Changes with Effective Dates and History

Extend an HR application's employee Edit tab so a user can schedule future changes to manager, department, salary, and title. Persist them in the existing EmployeeHistory table and show them in the History tab. Cancellation is out of scope for the initial version. ### Constraints and Clarifications An effective date cannot precede the employee's hire date or follow the termination date. For changes effective on the same day, a later submission overrides an earlier value only for the same field; changes to different fields combine. Clarify the business timezone and ordering of simultaneous submissions. Use a server-assigned revision order as an explicit practice convention, not a client clock. ### Part 1 — Scheduled Edits and History Define the frontend, API, and persisted representation for partial field changes and same-day merging. #### What This Part Should Cover Reuse durable history, validate the employment-date bounds, and retain per-field revision semantics without overwriting unrelated changes. ### Part 2 — Applying Changes How do you ensure a scheduled change becomes effective on its date? Address concurrency, idempotency, and errors. #### What This Part Should Cover Define authoritative current state and recovery from missed or repeated scheduling attempts. ### Part 3 — Backdated Changes How would you support a change whose effective date is in the past? #### What This Part Should Cover Recompute affected later state consistently, preserve an audit history, and explain downstream consequences. ### What a Strong Answer Covers A complete state and persistence model, per-field conflict rules, a reliable application path, and UI behavior based on confirmed server state. ### Follow-up Questions - What happens if a later submission changes title but an earlier same-day submission changed salary? - How do you prevent a stale worker from overwriting a newer revision?