Add Scheduled Changes to an Employee Management System

An existing employee-management system allows HR users to change employee salary, level, and title. Extend it with a scheduled-update feature so that a change can be recorded now and applied later. Explain the changes you would make to the existing application, the lifecycle of a scheduled update, and how you would demonstrate that the feature works. The existing codebase and its interfaces are not supplied here, so this exercise asks for an implementation plan and pseudocode-level reasoning rather than code against an invented API. ### Constraints & Assumptions - Preserve the existing ability to update employee information immediately. - Salary, level, and title are the reported examples of editable fields; do not assume that every employee field is writable. - Scheduling rules, persistence technology, authorization model, time-zone policy, and conflict semantics must be clarified. - Any retry, cancellation, or audit behavior you propose is a design decision to justify, not an already specified interface. ### Clarifying Questions to Ask - Does a scheduled change store absolute new values or a relative operation such as a percentage increase? - Which time zone defines the requested effective time, and how precisely must execution occur? - If an employee changes before the scheduled update runs, should it overwrite, merge, fail, or require review? - Can a scheduled update be edited or canceled, and what happens if the employee no longer exists? ### Part 1 — Integrate the Feature Explain what you would inspect in the existing code and where you would add scheduling support. Describe how the new path shares appropriate validation and authorization with immediate updates without applying the change prematurely. #### What This Part Should Cover - The current update path, persistence boundaries, and background-work facilities. - A durable representation of the intended change and effective time. - Field validation and permissions, including which checks must be reconsidered at execution time. - A clear separation between accepting an update request and applying it. ### Part 2 — Execute and Verify Scheduled Changes Describe how due changes are found, claimed, applied, and marked complete. Explain failures, duplicate processing, and the evidence you would use to verify behavior. #### What This Part Should Cover - An explicit lifecycle and concurrency strategy. - A policy for changes made between scheduling and execution. - Atomicity or idempotency around applying the change and recording completion. - Focused checks for timing, invalid fields, conflicting updates, and retried execution. ```hint Trace a worker crash after the employee record changes but before the scheduled update is marked complete. What prevents a retry from changing the meaning of the request? ``` ### What a Strong Answer Covers The response should fit the feature into an existing application instead of replacing the whole system. It should make time and conflict semantics explicit, reuse the appropriate domain logic, and connect each failure case to a concrete state transition or verification step. ### Follow-up Questions - How would you implement cancellation if a worker has already claimed the change? - Would an absolute salary replacement and a relative salary increase have the same retry behavior? - How would you distinguish a change that is waiting for its effective time from one that is overdue?